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MINUTES  OF  THE  FIFTH  ANNUAL  MEETING 
INTERNATIONAL  PURDUE  WORKSHOP  ON  INDUSTRIAL 
COMPUTER  SYSTEMS 


Purdue  University 
October  3-6,  1977 


f CHAPTER  I 

INTRODUCTION 

1 • Organization 

7/>o  a r r/.<.  ° 

The  Fifth  Annual  Meeting  of  the  International  Purdue 

Workshop  on  Industrial  Computer  Systems, met  at  Purdue  Uni- 

t/.s.  A. 

versity,  West  Lafayette,  Indiana,  on  October  3-6,  1977. 

Those  individuals  listed  in  the  Appendix  I registered 
for  the  meeting.  The  Agenda  of  Insert  I was  followed. 

Mr.  Nicholas  E.  Malagardis,  Chairman  of  Purdue -Europe, 
presented  the  report  of  the  European  Regional  Meeting  and 
the  events  which  had  occurred  there  since  that  meeting. 
Insert  II  reproduces  his  report. 

Professor  Mitsuru  Terao  presented  the  corresponding 
report  of  the  Japanese  Regional  Meeting  and  of  the  activi- 
ties of  Purdue- Japan.  His  report  is  given  in  Insert  III. 

<■■■■■■■»»  1 1 n 


«& 


PHECEQIWO  PASS  BLANK 
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2.  Mr.  Richard  L.  Curtis  | 

It  is  with  deep  regret  that  we  announce  the  death  on 
Wednesday  evening,  December  28,  1977,  of  Mr.  Richard  L. 

Curtis . Dick  was  very  active  with  the  International  Purdue 
Workshop  and  had  served  us  in  a wide  variety  of  posts  in- 
cluding Vice  Chairman  of  Planning,  Chairman  of  the  Functional 
Requirements  Committee,  and  of  the  Interface  and  Data  Com- 
munications Committee  and  as  a very  active  member  of  the 
Executive  Committee. 

Dick  was  Manager,  Process  Control  Computer  Systems  for 
the  Aluminum  Company  of  America  and  was  instrumental  in  the 
major  strides  which  that  company  has  made  in  the  industrial 
computer  control  field. 

We  will  miss  his  enthusiasm  and  his  wise  counsel  in  the 
Workshop . 

3 . Professor  Mitsuru  Terao 

Professor  Mitsuru  Terao  has  reported  to  us  that  he  will 
retire  from  his  position  as  Professor  of  Mathematical  Engi- 
neering and  Instrumentation  Physics  at  the  University  of 
Tokyo  in  March  1978.  As  a result  he  will  resign  from  his 
Chairmanship  of  the  IPW  Committee  of  JEIDA  or  Purdue- Japan. 

As  is  outlined  on  page  18  of  the  Minutes  of  the  Fourth 
Annual  Meeting,  he  has  also  served  as  Chairman  of  the  Ad-Hoc 
Committee  for  Standardization  of  Industrial  Computer  Systems 
also  of  JEIDA. 


i 


AM 

08:00  - 08:30 
03:30  - 03:45 


08:45  - 0Q : 00 


09:00  - 09:15 


INSERT  I 


ACKNDAS  AND  SCHEDULES 


FIFTH  I NTERNAT 1 ON  AT,  MEETINC 


INTERNATIONAL  PERDUE  WORKSHOP 


ON  INDUSTRIAL  COMPUTER  SYSTEMS 


Room  310 
Stewart  Center 
Purdue  University 
West  Lafayette,  Indiana  47907 


October  3-6,  1977 


Monday , October  3 , 1977 


Registration  - Room  310,  Stewart  Center 

Introduction  and  Discussion  of  Workshop 
Program.  Introduction  of  Committee  Chairman. 
Committee  Plans. 

Report  of  the  European  Regional  Meeting 
and  Planned  Activities. 

Mr.  Nicholas  E.  Malagardis 
Regional  Chairman 

Report  of  the  Japanese  Regional  Meeting 
and  Planned  Activities 

Dr.  Mitsuru  Terao , Chairman 
Committee  for  Standardization  of 
Industrial  Computer  Systems 


09:15  - 09:30 


Coffee  Break 
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09:30  - 10:30 


M 

10:30  - 12:00 

12:00  - 01:30 
PM 

01:30  - 02:30 


02:30  - 02:45 
02:45  - Close 


AM 

08:30  - 09 : 30 


09:30  - 09:45 


INSERT  I (Cont.) 


A Tutorial  Discussion  on  the  Topic: 

"The  Applications  of  Microprocessors 
to  Process  Control" 

Mr.  Thomas  G.  Caspar 
Director,  Automation  Control 
Merck  & Co . , Inc . 

Rahway,  New  Jersey 

Meetings  of  the  Workshop  Committees 
as  Called  by  the  Chairmen. 

Lunch 


"A  Report  on  the  Status  and  Future  Program 
of  the  Higher  Order  Languages  Working  Croup 
of  the  U.S.  Department  of  Defense" 

Lt.  Col.  William  A.  Whittaker 
Advanced  Research  Projects  Agency 
Arlington,  Virginia 

Coffee  break 

Meetings  of  the  Workshop  Committees 
as  Called  by  the  Chairmen. 


Tuesday , October  4,  1°77 


A Tutorial  Discussion  of  the  "Standardisation 
Efforts  in  West  Germany  in  the  Field  of 
Safety  and  Reliability  and  Security" 

Dr.  Rudolph  Konakovsky 
Inst itut  fur  Regelungstechnik  und 
Prozessautomatisi erung 
University  of  Stuttgart 
Seidenstrasse  3b 
D- 7000  Stuttgart  1 
GERMANY 

Coffee  break 


M 

09:45  - 12:00  Meetings  of  the  Workshop  Committees 

as  Called  by  the  Chairmen. 


— ' ~ —■ 


i 


£ 


12:00 

01:30 


01  : 30 

02  : 30 


02:30  - 02:45 
02:45  - Close 

08:00  - Close 

AM 

08:30  - 09:30 
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Lunch 

Organizational  Meet  ing 
International  runlue  Workshop  on 
Industrial  Computer  Systems 

Leport  of  the  Executive  Committee 

Actions  and  Proposals 

Report  of  the  Vice  Chairman  for  Standards 

Dr.  Thomas  J.  Harrison 
Vice  Chairman 

Report  of  the  Vice  Chairman  for  Planning 

Mr.  Robert  S.  Crowder,  Jr. 

Vice  Chairman 

Report  of  the  Nominating  Committee 

Mr.  Richard  li.  Caro 
American  Regional  Chairman 

Election  of  Officers 

Discussion  of  Workshop  Structure. 

Coffee  Break 

Meetings  of  the  Workshop  Committee 
as  Called  by  the  Chairmen. 

Meetings  of  the  American  Regional  Branch 
and  of  the  IJSTAO,  IS0/TC97/SC5/W01 . 

Wednesday , October  5,  1977 

"Tasking  - Past  and  Present" 

Dr.  Matthew  Cordon-Clark 
Chairman 

Panelists : 


i 


i 


Mr.  Richard  H.  Caro 
The  Foxboro  Company 
Foxboro , Massachusetts 
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Professor  Odd  Petersen 
Norwegian  Inst,  of  Technology 
Div.  of  Engineering  Cybernetics 
7034  Trondheim-NTH 
Norway 

Mr.  Alex  J.  Arthur 
IBM  Corporation 
San  Jose,  California 

Mr.  Peter  Elzer 
Tandemlabor 
Physics  Institute  III 
University  of  Erlangen 
Erlangen,  Certnanv 

Dipl-Ing.  Thierrv  Lalive  d'Epinay 
Hybridrechenzentrum  der  ETH 
Voltastrasse  18 
Cl! -8044  Zurich 
Switzerland 

09:30  - 09:45  Coffee  Break 


M 

09:45  - 

12:00 

Meetings  of  the  Workshop  Committee 
as  Called  by  the  Chairmen. 

PM 

12:00  - 

01:30 

Lunch 

01:30  - 

02:30 

IBM  Series/ 1 PL/I 

Mr.  Alex  J.  Arthur 

The  IBM  Company 

San  Jose,  California 

02:30  - 

02:45 

Coffee  Break 

02:45  - 

Close 

PM 

Meetings  of  the  Workshop  Committee 
as  Called  by  the  Chairmen 

08:00  - 

09:00 

PL/M  - A High  Level  Programming  Language 
for  Microprocessor  Application 

Mr.  Thomas  S.  I.ehman 
Manager  of  Training,  Midwest 
Intel  Corporation 
Oak  Brook,  Illinois 
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Thursday  , Oct  i >her  6 , 197  7 


AM 

08:30  - 09:30 


09:30  - 09:45 
09:45  - 12:00 

M 

12:00  - 01:30 
01:30  - 01:45 


"The  Impact  of  New  Trends  in  Hardware  on 
Computer  System  Interfaces" 

R.  Warren  Gellie 
Chairman 

Panelists : 

Mr.  Anthony  O.  Deramo 
We s t inghous e El ec tr i c 
Orlando,  Florida 

Mr.  Charles  Farmer 
Hone  well,  Inc. 

Ft.  Washington,  Pennsylvania 

Dr.  Daniel  T.  W.  Sx.e 
IBM  Corporation 
Boca  Raton,  Florida 

Coffee  Break 

Meetings  of  Workshop  Committees  as 
Scheduled  by  the  Committee  Chairmen 


Lunch 

Presentation  of  Results  of  Del iverat ions 
of  the  FORTRAN  Committee 

Dr.  Matthew  Gordon-Clark 

Voting  on  any  Proposals  Arising  from 
FORTRAN  Committee  Work 

Presentation  of  Results  of  Work  of  the 
Systems  Reliability , Safety,  and  Security 
Committee 


Mr.  Roy  W.  Yunker 
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01:45  - 02:00 


02:00  - 02:15 


02:15  - 02:30 
02:30  - 02:45 


02:45  - 03:00 


03:00  - 03:30 


03:30  - 03:45 


INSERT  I (Cont.) 

Presentation  of  Results  of  Deliberations 
of  the  Man/Machine  Interface  Committee 

Mr.  Lyle  Simon 

Voting  on  any  Proposa] s to  be  Made  by 
the  Committee 

Presentation  of  Results  of  Work  of  LTPL 
Committee  and  Discussion  of  the  IRONMAN 
Review 


Mr. Peter  Elzer 

Voting  on  any  Proppsals  to  he  Made  by 
the  Committee 

Coffee  Break 

Presentation  of  Results  of  the  Interface 
and  Data  Transmission  Committee 

Mr.  R.  Warren  Gel lie 

Voting  on  any  Proposals  to  be  Made  by 
the  Committee 

Operating  System  Committee 

Dipl-Ing.  Thierry  Lalive  d'Epinav 

Voting  on  any  Proposals  to  be  Made  by 
the  Committee 

Presentation  of  Results  of  Work  of  the 
Problem-Oriented  Languages  Committee 

Mr.  Nicholas  E.  Malagardis 
Dr.  Theodore  J.  Williams 

Voting  on  any  Proposals  to  be  Made  by 
the  Committee 

Presentation  of  Results  of  Work  of  the 
BASIC  Committee 

Mr.  Richard  H.  Caro 

Voting  on  any  Proposals  to  be  Made 
bv  the  Committee 
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03:45  - 04:00  Microcomputer  Ad-lloc  Committee 

Mr.  Yo el  Keiles 

llonevwell,  Inc. 

04:00  - 04:15  Report  of  the  Deliberations  of  the  USTAG 

of  IS0/TCQ7/SC5/W01  of  Tuesday  evening. 

Dr.  Thomas  .1.  Harrison 

04:15  - 05:00  New  Business 

Discussion  of  Time  of  Next  Meeting 

of  Workshop 


' T *** 


r 


j 
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AGENDA 


MEETINGS  OF  THE 

REAL-TIME  FORTRAN  COMMITTEE  (TC-1) 


October  3-6,  1977 


The  FORTRAN  Committee  (TC-1)  will  devote  most  of  its  time  to 
consideration  of  S61-3.  In  particular,  the  complete  technical 
contents  of  this  document  will  be  decided  on  at  this  meeting. 

The  details  of  the  actual  document  will  not  be  decided  at  the 
meeting  but  no  new  ideas  or  features  will  be  included  after 
this  meeting.  This  will  permit  the  Committee  to  resolve  the 
detailed  description  of  the  standard  in  the  subsequent  meetings. 
All  persons  having  an  interest  in  the  standard , which  covers 
tasking  on  the  mechanisms  for  inter  program  control,  are  urged 
to  attend  this  meeting.  Any  ideas  submitted  to  the  Committee 
after  this  meeting  will  be  deferred  until  another  standard  is 
developed  or  until  the  current  standards  are  reviewed  (this 
occurs  every  five  (5)  years) . 

The  content  of  S61-3  concerns  what  is  generally  called  "task- 
ing". Over  recent  years  the  Committee  has  developed  a state 
diagram  to  describe  the  tasking  problem  which  is  Markovian 
(the  transition  from  each  state  is  independent  of  the  transition 
into  the  state)  and  uses  the  concept  of  a virtual  processor. 

With  this  model,  the  following  application  areas  have  been 
considered  for  a task. 

Initiation 
Termination 
Exception  Handling 
Task  Synchronization 
Critical  Regions 
Inter-Task  Communications 
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Recent  Committee  meetings  (Purdue,  April  '77  and  Foxboro,  June 
'77)  have  decided  to  include  initiation,  termination,  approp- 
riate exception  handling,  and  basic  task  synchronization  in  the 
standard.  Critical  regions  are  not  included  as  requiring  a 
"block"  concept  which  is  common  in  many  languages  (ALGOL,  PL/1) 
but  does  not  exist  in  FORTRAN.  Inter- task  communication  is 
also  left  out  of  the  standard  as  it  was  considered  that  files 
could  be  used  for  this  purpose  with  the  resolution  of  all  con- 
tention problems  using  S61-2-1977. 

It  is  hoped  that  a draft  S61-3  will  be  ready  by  the  1st  of 
September,  1977.  This  will  be  sent  to  all  Committee  members. 
Anyone  else  who  warts  a copy  before  the  Purdue  meeting,  please 
let  me  know. 

The  agenda  for  the  next  meeting,  (not  necessarily  in  this  order) 
will  be: 

Report  on  ISA  S61-1-1976 
Report  on  ISA  S61-2-1977 
Report  on  ANSI  X3J3 

Report  from  the  American  Region  of  IPW-TC1 
Report  from  the  European  Region  of  IPW-TC1 
Report  from  the  Japanese  Region  of  IPW-TC1 
Discussion  of  Draft  S61-3. 

IF  YOU  WISH  TO  INFLUENCE  THE  CONTENTS  OF  THE  FORTRAN  STANDARD 
ON  TASKING,  BE  SURE  TO  COME  TO  THIS  MEETING. 

THIS  IS  YOUR  LAST  CHANCE. 


Matthew  R.  Gordon-Clark 
Chairman 
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AGENDA 

ME  EATINGS  OF  THE 

REAL-TIME  BASIC  COMMITTEE  (TC-2) 

October  3-6,  1977 

1.  Report  on  IRTB  Activities. 

2.  Approval  of  Standardization  Agreement. 

3.  Discussion  of  ANSI/ECMA  Standard. 

4.  Discussion  of  IRTB  Standards  Proposal. 

5.  1978  Activities. 

6.  A.O.B. 


| 


Eric  Crichton 
Chairman 
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AGENDA 

MEETINGS  OF  THE 

LONG  TERM  PROCEDURAL  LANGUAGES  COMMITTEE  (TC-3) 

October  3-6,  1977 

Monday , October  3,  1977 

Administration  and  Planning 
Tuesday . October  4,  1977 

Discussion  of  "IRONMAN" 

Wednesday , October  5,  1977 

Further  Discussion  of  the  Green  Sheets 


Johannes  Reh 
Chairman 


i:.  .. 
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AGENDA 

MEETINGS  OF  THE 

PROBLEM- ORIENTED  LANGUAGES  COMMITTEE  (TC-4) 

October  3-6,  1977 

Monday , October  3,  1977 

Activities  of  the  TC  POL 
Tuesday , October  4,  1977 

Work  of  TC  POL  in  Europe 
Wednesday  , October  _5 , 1977 
Requirements  of  POL 


It 

Guente1-  Musstopf 
Chairman 
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AGENDA 

MEETINGS  OF  THE 

INTERFACES  AND  DATA  TRANSMISSION  GUIDELINES  COMMITTEE  (TC-5) 


October  3-6,  1977 

1.  Review  of  Document  IEC-SC6T>A/W06  (Japan-2) 

2.  Presentation  of  Honeywell's  TDG2000  Evaluated 
Against  Japan  Document 


3.  Report  on  IEC-SC65A/WG6 


4.  Discussion  of  Future  Work  Program 


5.  On  Wednesday  morning,  October  5,  we  will  have  a special 

presentation  (film  and  demonstration)  of  the  fundamentals 
and  current  technology  on: 

Fiber  Optics  Communication  Links 

Mr.  Carl  Podlesny 

Senior  Applications  Engineer 

and 


Mr.  Rodney  Andersen 

Marketing  Manager  for  Communication  Fibers 
both  from 


Galileo  Electro  Optics  Corporation 
Galileo  Fark 

Sturbridge,  Massachusetts  01518 


i 


R.  Warren  Gellie 
Acting  Chairman 
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AGENDA 

MEETINGS  OF  THE 

MAN-MACHINE  COMMUNICATIONS  COMMITTEE  (TC-6) 

October  3-6 , 1977 

Monday , October  '3_,  1977  (2:45  PM  - Close) 

Finalization  of  Bibliography 

Tuesday , October  4,  1977  (9:45  AM  - Noon) 

Device- Independent  Language  Specificat ions 

Wednesday , October  5,  IP 77  (°:45  - Noon) 

Justification  for  Man/Machine  Interface 


Robert  F.  Carioll 
Chairman 


AGENDA 


MLET1NCS  OF  THE 

SYSTEMS  RELIABILITY,  SAFETY,  AND  SECURITY  COMMITTEE  (TC-7) 

Monday , October  3 , 1977 

1.  Introduction  of  Members 

2.  Review  of  Objectives  and  Committee  Purpose 

3.  Questions  for  Committee  Discussion 

a.  What  Are  Realistic  Objectives  for  TC-7 
Relating  to  Guidelines,  Standards  and/or 
Certification? 

b.  What  Would  Your  Company  or  Affiliation  Like 
to  See  Emerge  as  A Safety,  Security  and 
Reliability  System? 

c.  Comments  by  Attendees  Relating  to  Individual 
Interest . 

Tuesday , October  4,  1977 

Review  of  TC-7  (Europe,  Japan,  and  America)  and 
Interrelationships  and  Mutual  Goal 

Further  Question  Discussion 

Establishment  of  Criteria  for  Hardware  and  Software 
Reliability 

Wednesday , October  5 , 1977 

Development  of  Strategy  and  Organization  of  Committee 
Discussion  of  Membership  Plan 

Final  Summary  of  the  Committee  Strategy  and  Plans 
for  the  Coming  Year. 


Roy  W.  Yunker 
Chairman 


Monday , October  3,  1977 


Presentation  of  on-going  work  and  results  of  the 
Regional  Committees  (1  hour) . 

Discussion  of  the  questionary  of  TC  8/A  on  the 
Report  IV-1-4  of  TC  8/E. 


Tuesday , October  A,  1977 


Presentation  of  the  new  up-to-date  Report  IV- 1-5  of 
TC  8/E . 

Discussion  and  decisions,  to  accept  the  different 
parts  of  the  Report  or  suggested  changes  respectively. 


Wednesday,  October  5,  1977 


Coordination  of  future  work  of  the  Regional  Committees. 
Possibilities  of  creating  an  internationally  approved 
Report,  combining  the  work  of  the  Regional  Committees. 


\ 


NOTE:  It  would  be  possible  to  have  a general  presentation 

of  the  new  Up-to-date  Report  of  TC  8/E  which  could  be 
attended  by  all  interested  participants  of  the  meeting. 


Thierry  LaLive  d'Epinay 
Chairman 
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PURDUE  EUROPE  CHAIRMAN'S  REPORT 


During  the  past  year  Purdue  Europe  has  been  reinforced  In 
participation  members  and  the  label  Purdue  Europe  is  becoming 
slowly  but  surely  well  known  to  industry  and  standardization 
milieu  in  the  old  continent. 

Since  it  is  fashionable  and  has  been  requested  that  view 
graphs  be  used  and  since  this  will  ease  the  comprehension  of  the 
relationships,  let  me  show  you  how  we  situate  Purdue  Europe  (Eig.l). 

I think  this  shows  you  more  than  T could  tell  in  a pure 
sequential  manner  and  particularly  with  my  deficient  mastering 
of  the  Anglo  American  language. 

1 nave  said  during  my  previous  reports  in  this  room  that 
when  working  within  Purdue  Europe  one  stumbles  on  t he  complexi- 
ties and  byznntinisms  of  international  committees. 

So,  the  only  body  on  which  we  could  rely  upon  was  and  is 
the  Commission  of  the  European  Communities  (CFC) : this  does  not 
make  things  as  easy  for  us  as  one  could  suppose  since  this  or- 
ganization has  to  take  care  of  all  kinds  of  subtle  conditions 
and  thus  create  a consensus  before  reaching  a decision. 

When  proposing  projects  to  the  Council  of  Ministers,  the 
Commission  has  to  prepare  the  way  by  a great  number  of  paths 
through  which  explanations  have  to  be  given  at  every  instance 
for  those  feeling  concerned  and  who  wish  to  discuss  the  matter 
on  the  opportunity.  (Fig.  2). 


INSERT  II  (Cont.) 


You  see  that  when  I was  speaking  of  a considerable  amount 
of  difficulties,  I was  not  exaggerating  at  all. 

Let  me  tell  you  and  maybe  bore  you  about  the  LTPL  project 
or  ERTL  as  our  British  colleagues  like  to  call  it.  One  has  the 
feeling  he  is  coming  down  that  stair  (Fig.  3). 

This  proposal  has  twice  reached  the  status  of  a project, 
but  the  intentions  behind  it  have  never  been  clarified  between 
the  partners.  I must  confess  to  my  opinion  that  the  LTPL-E 
group  did  not  arrive  at  a set  of  clear  and  cleanly  integral 
specifications  before  the  project  was  discussed  at  the  various 
decision  levels.  So  we  are  still  in  the  initiation  of  a project 
which  tends  nevertheless  to  have  a certain  profile  which  is  at 
the  point  of  being  admitted  but  is  being,  continuously  postponed. 

Meanwhile,  Purdue  Europe  (The  name  I was  told  sounds  very 
American,  but  we  are  going,  to  keep  it  in  spite  of  our  detractors) 
has  passed  a motion  offering  the  Commission  its  potential  of 
expertise  and  know  how. 

What  we  can  expect  from  them  is  the  following:  (live  us  a 
technical  mandate  as  far  as  their  technical  plans  are  concerned, 
continue  supporting  our  meetings  and  even  support  some  travel 
expenses  especially  to  the  U.S.A.  Consider  Purdue  Europe  as  a 
technical  expert  body  in  questions  of  industrial  computer 
standards  development  . 

The  relationship  with  the  CEC  now  appears  clear  and  has  been 
to  a degree  officialized  with  our  meeting  taking  place  at  ISPRA, 
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at  the  Euratom  Research  Center.  This  meeting,  took  place  with 
the  full  support  of  the  Communities. 

At  that  meeting  a first  official  contact  with  ECMA  took 
place;  this  was  in  parallel  to  the  now  established  collaboration 
with  TC  2 RT  BASIC  who  work  together  in  a common  group  with  ANSI. 

Participation  in  that  meeting  was  more  than  100,  with  eight 
participants  from  the  Eastern  European  countries  and  5 Americans. 

The  Workshop  had  an  excellent  tutorial  by  Prof.  I.C.  PYLE 
on  structured  programming  and  two  panels  on  microprocessors: 

(1)  "The  Influence  of  Microprocessors  on  Industrial 

Computer  Systems,"  which  was  chaired  by  Prof.  J. 

NICOUD  of  the  University  of  1JU1SANNE . 

(2)  "The  Influence  of  Distributed  Intelligence  on 

Programming,"  chaired  by  Prof.  R.  BAUMANN  of  the 

University  of  MUNICH. 

The  interest  in  what  is  happening  in  the  microcomputer 
field  is  confirmed  by  the  main  topics  of  this  International 
Workshop.  This  topic  is  also  closely  followed  by  the  European 
Distributed  Intelligence  Study  Croup,  EDISG,  whose  birth  was 
announced  last  year  and  which  is  very  active  in  trying  to 
elaborate  some  concrete  rules  in  interfacing  and  mastering 
software  in  the  microprocessors.  As  can  bo  easily  understood, 
the  group  is  hesitating  whether  or  not  to  include  communica- 
tion procedures  in  its  basic  work. 


L 


Purdue  Europe  presented  its  achievements  and  current 
activities  to  a Workshop  on  Possible  Community  Actions  in  Real 


Time  Informatics  organized  by  the  Commission  in  Brussels. 
Attendees  were  impressed  by  the  work  done  and  asked  the 
Commission  to  take  into  consideration  the  activities  of 
Purdue  Europe.  Special  importance  was  accorded  to  papers 
presented  by  EKRENBERGER  and  TAYLOP  of  TC  7 and  PENNIALL  of 
TC  6.  The  Minutes  of  that  Workshop  are  available  from  M. 
DESFOSSES  DG  III  Commission  of  the  European  Communities, 
rue  de  la  Loi  200,  B-1048  BRUSSELS,  BELGIUM. 

Coming  to  some  organizational  details  now  I'm  not  going 
to  comment  on  all  TC  activities  one  by  one  but  I would  like  to 
mention  the  difficulties  in  the  communications  between  the 
American  and  European  FORTRAN  Committees. 

Another  matter  of  concern  is  our  liaison  with  the  Japanese 
regiotial  organization  or  should  I say  the  non  existence  of  any 
liaison.  We  do  not  know  what  they  are  doing  or  who  they  are. 
From  time  to  time,  there  is  a copy  of  a letter  when  they  write 
to  Ted  WILLIAMS  and  by  that  means  we  know  that  structures  have 
been  changed  but  almost  nothing  on  any  special  kind  of  work. 

Computer  Science  or  Informatics  as  we  say  in  Europe  is 
a world-wide  phenomenon  and  standards  practices  is  a world- 
wide phenomenon  and  this  is  an  International  Workshop  whether 
we  like  it  or  not.  Omphaloskepsis , navel  contemplation,  does 
not  lead  to  anything  but  bad  understanding  and  entertains 
suspicion . 

So,  allow  me  to  make  an  appeal  for  a better  circulation 


of  ideas. 
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Report  of  the  Japanese  Regional  Meeting 

and  Planned  Activities 
— 

The  works  on  Industrial  Computer  Systems  in  Japan 
Electronic  Industry  Development  Association  (JEIDA)  have 
been  carried  by  four  technical  committees  of  standardization, 
safety,  software,  hardware  and  survey  as  shown  in  Figure 
1.  Each  committee  consists  of  fifteen  to  twenty  fixed 
members.  They  held  monthly  meeting  to  discuss  the  specified 
subjects  and  prepared  four  annual  reports  published  by 
JEIDA  as  A-114 , A-115,  A-116  and  A-117. 

j 

The  Japanese  Regional  Meeting  of  the  International 
Purdue  Workshop  on  Industrial  Computer  Systems  took  place 
in  Room  66,  67  and  B-2,  JEIDA,  Tokyo,  Japan,  on  June  29- 
30,  1977  in  conjunction  with  the  annual  meeting  of  JEIDA 
committees  on  Industrial  Computer  Systems.  The  sixty 
individuals  registered  for  the  meeting.  It  was  opened 
to  all  interested  people  and  the  reports  were  distributed 
to  them  as  a text.  One  of  the  important  function  of  the  meeting 
was  that  the  members  of  the  four  committees  could  have  a chance 
to  discuss  their  activities  with  attendants.  The  activities 
of  International  Workshop  on  Industrial  Computer  Systems  were 
also  reported  in  the  meeting  and  especially  through  the  JEIDA 
report  A--117. 


{■  ■ 

* 
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Systems  has  been  worked  for  standardization  of  hardware 
proof  testing  procedures  as  to  the  following,  components: 

1)  CPU 

2)  Auxiliary  devices 

3)  Data  input-output  devices 

4)  Process  input-output  devices 

5)  Operator  console 

6)  Power  source 

Cooperating  with  the  Standardization  Committee  they  are 
now  planning  to  prepare  a formal  document  to  bring  their 
result  into  the  JEIDA  standard. 


2 . Standardization  of  Documentation  for  Requirement 
Specification 

To  insure  that  the  requirements  of  the  users  can  be 
conveyed  to  the  venders  of  software  exactly,  the  Committee 
for  Standardization  of  Industrial  Computer  Systems  organized 
a Working  Group  on  Standardization  of  Documentation  Proce- 
dures for  Software  Requirement  Specifications.  They  made  a 
guideline  of  documentation  procedures  as  to  the  following 
items : 

1)  Controlled  plant 

2)  Function  of  the  computer  system 

3)  Position  of  the  computer  system  in  total  system 

4)  Back-up  systems 

5)  Process  input  and  output  ^rt.- m . ..  - 

6)  Process  operator  onsole  ■ < PRECEDING  FJOS  BLAJK 
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7)  Printing,  logging  and  message 

8)  Data  handling 

9)  File 

10)  Sequence  control 

11)  Control  loops 

12)  Control  terms 

13)  Data  communication 

14)  Background  job 

15)  System  performance 

16)  Program  language 

17)  Application  software 

18)  Schedule 

They  understand  that  their  result  is  only  a preliminary 
draft  for  standardization  and  are  planning  to  distribute 
the  draft  to  hear  some  comments  of  various  users. 


3 . Investigation  of  Japanese  Dataway  Systems 

The  Sub-Committee  for  Hardware  of  Industrial  Computer 
Systems  investigated  the  formats  and  control  procedures  as 
to  the  following  dataway  systems, 


F-Bus 

H-7480  DFW 
S-Type  DHW 
MELCOM-LOOP 
RDAS-1000 


Yokogawa 

Hitachi 

JSE 

Mitsubishi 

Toshiba 


HDLC  oriented 
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N6720  Model  2 
FACOM  1880 


NEC 

Fujitsu 


J 


PCM-24  oriented 


TDCS-2000 

RINCS 

MPCS 


Honeywel 1 
Hokushin 
Fuji  Electric 


4 • Document  IEC/SC65A/WG6 

Reffering  the  result  of  the  investigation  of  Japanese 
dataway  systems  the  Committees  for  Hardware  and  Standard- 
ization made  joint  work  cooperating  with  IEC  SC65A/WG6 
(inter-subsystem  communication)  to  prepare  the  proposed 
guideline  for  implementation  of  industrial  process  computer 

inter-subsystem  communication  ( IEC/SC65A/WG6 , Japan-2) 
which  consists  of  following  seven  chapters: 

1.  Introduction 

2.  Application  Environments 

3.  Functional  Specification 

4.  Architecture 

5.  Protocol 

6.  Safety  and  Security 

7.  Maintenance 

5 . Guideline  of  System  Environment 

The  Committee  on  the  Safety,  Security  and  Reliability 
of  Computer  Systems  worked  for  guidelines  of  installation 
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surrounding  and  maintenance  of  industrial  computer  systems. 
The  installation  environments  of  the  systems  varies  widely 
so  that  the  obstacles  caused  by  environment  are  increasing. 
One  of  the  problems  pointed  out  here  is  the  lack  of  dura- 
bility against  environment  of  hardware,  and  the  other  is 
the  lack  of  user's  consideration  about  the  installation 
environment.  In  order  to  solve  these  problems,  the  clari- 
fication of  environmental  condition  on  both  sides  of  users 
and  makers  is  considered  necessary.  The  installation  envir- 
onment guideline  was  made  as  the  first  step. 

I 

They  have  a plan  to  continue  the  efforts  and  are  go- 
ing to  revise  the  guideline  hearing  comments  from  various 
users . 


6 . Guideline  of  System  Maintenance 

The  Committee  on  the  Safety  has  a plan  to  prepare  a 
guideline  of  system  maintenance  but,  in  the  year  of  1976, 
they  only  investigated  the  present  status  of  the  recommended 
system  maintenance  through  questionnaire  to  twelve  systems 
manufacturers  and  discussed  the  items  which  should  be 
included  the  maintenance  guideline.  They  will  continue 
their  effort  to  complete  the  guideline. 


7 . Investigation  of  High  Level  Languages 

The  Committee  on  Software  investigated  the  recent 
developments  of  high  level  languages  in  Japanese  computer 
systems  manufacturers  as  to  the  following  items: 


L 
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1)  Base  language 

2)  Character  number  of  Label  and  variables 

3)  Data  type 

4)  Default  interpretation 

5)  Alocation  to  the  storage 

6)  Common  variables  among  task 

7)  Virtual  variable  in  external  storage 

8)  Dimension  of  array 

9)  Data  type  Structure 

10)  Extensibility  of  the  Languages 

11)  Operation  on  character  string  or  bit  string 

12)  Interrupt  handling 

13)  Access  to  external  storage 

14)  File- type 

15)  Input/Output  of  Typewriter  and  CRT 

16)  Statement  for  debagging 

1 7 ) Rea  1 t i me  f ac i 1 i ty 

L0)  Process  1/(1  access  facility 
19)  Others 

8.  Investigation  of  Opera t imj  Systems 

The  Committee  on  Software  investigated  the  present 
status  of  the  operation  systems  as  to  the  following 
i terns : 

1)  Tasking 

2)  Input/Output  control  program 
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3)  File  handling 

4)  Standardization  of  computers  communication 

and  published  the  detail  of  following  operating  systems 
in  JEIDA  report  A-117(1976): 


Manufacturer  I Computer  system  I Operating  system 


Toshiba 

TOS0AC-4O 

POPS 

Yamatake 
-lloneywe  1 1 

US  716 

OP  716 

Mitsubishi 

MELCOM  150 

TSOS 

Pan a Fa com 

Series  U 

UMOS 

Hokush i n 

Hoc- 9 00 

OTOS  3 

Yokogawa 

YODIC  100 

YOS-MP 

Fuji  Electric 

Series  U 

POPS 

Shinko  Electric 

sees 

SOS 

Nippon  Electric 

N E AC  3200/70 

COM  32 

Hi tach i 

HIDIC  80 

TSES/PMS 

They  are  going  to  make  some  standardization  for 
operating  system,  at  least,  as  to  the  concept  and  glossary. 

9.  Trends  of  Industrial  Computer  Systems 

The  committee  for  survey  on  industrial  computer 
systems  investigated  the  current  state-of-art  of  industrial 


-38- 


IMSERT  III  (Cont.) 

computer  systems  in  Japan  and  published  detailed  report 
through  JEIDA  report  A-114.  The  report  is  the  survey  on 
the  developments  of  system  architecture*  main  frame, 
software  and  microcomputers.  They  are  planning  to  make 
further  investigation  of  standardized  package  of  appli- 


cations software. 
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Dr.  Kohei  Sato,  Chief,  Automatic  Control  Division, 
Electrotechnical  Laboratory,  will  replace  him.  We  are  all 
acquainted  with  Dr.  Sato  since  lie  has  attended  several  of 
the  Annual  Meetings  of  the  International  Purdue  Workshop 
and  its  predecessor  groups. 

We  will  miss  Professor  Terao's  major  contributions  to 
the  Workshop,  particularly  his  shepherding  of  Purdue  Japan. 

We  wish  to  thank  him  most  sincerely  for  his  very  great  help 
and  interest  and  wish  him  all  good  health  and  enjoyment  in 
his  retirement. 

We  welcome  Dr.  Sato  as  the  new  Chairman  and  look  forward 
to  working  with  him  in  all  our  future  activities. 

Mr . Johannes  Reh 

Another  major  loss  has  been  the  resignation  of  Mr.  Johannes 
Reh  as  Chairman  of  the  Long  Term  Procedural  Languages  Committee 
which  he  has  served  so  effectively  for  many  years.  Insert  IV 
reproduces  his  letter  of  resignation.  I am  sure  all  members  of 
the  workshop  join  in  thanking  Mr.  Reh  for  his  very  great  help 
to  the  Workshop  in  the  past,  particularly  during  the  early 
years  of  LTPL  and  wish  him  every  success  in  his  ever  increasing 
work  with  his  company.  We  hope  that  sometime  in  the  future  he 
can  once  again  join  with  us. 

Standards  Coordination 

Insert  V presents  the  report  of  the  Vice  Chairman  for 
Standards  Coordination,  Dr.  T.  J.  Harrison.  As  recorded  there, 
standards  activity  remains  high  and  the  coordination  task  has 
in  no  way  diminished  in  recent  time. 
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6 . Tutorials  ( 

A large  number  of  tutorial  presentations  were  made  at 
this  meeting  of  the  Workshop  as  the  result  of  the  request  of 
the  members  and  also  the  work  of  several  of  the  Technical  Com- 
mittees. Reprints  of  the  slides  and/or  writeups  of  several  of 
these  are  included  in  these  Minutes  at  Appendices  II-VII.  In 
addition  to  those  reproduced  here,  the  following  were  also 
presented. 

Lt.  Col  William  A.  Whitaker,  Chairman,  Higher  Order 
Languages  Working  Group,  U.S.  Department  of  Defense  presented 
a discussion  entitled,  "A  Report  on  the  Status  and  Future 
Program  of  the  Higher  Order  Languages  Working  Group  of  the  U.S. 

Department  of  Defense".  This  report  was  an  updating  of  that 
published  in  the  Minutes  of  the  1977  Spring  Regional  Meeting 
of  the  Workshop  on  pp.  657-666.  Col.  Whitaker  requested  the 
help  of  the  LTPL  Committee  in  further  evaluations  of  IRONMAN 
and  its  successors  and  in  review  of  the  forthcoming  proposals 
for  languages  from  their  current  contractors. 

Dr.  Matthew  Gordon-Clark  chaired  a tutorial  Round  Table 

discussion  entitled,  "Tasking-Past  and  Present".  The  Round 

Table  was  composed  of  himself  and  the  following  individuals: 

Mr.  Richard  H.  Caro 
The  Foxboro  Company 
Foxboro,  Massachusetts 

Professor  Odd  Petersen 
Norwegian  Institute  of  Technology 
7034  Trondheim  NTH,  Norway 


Mr.  Alex  J.  Arthur 
IBM  Corporation 
San  Jose,  California 
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INSERT  IV 


Johannes  Reh,  chairman  of  the  LTrL-commi tee 

INTERNATIONAL  PURDUE  WORKSHOP  ON 
INDUSTRIAL  COMPUTER  SYSTEMS 


Mr.  Prof.  Dr.  T.J.  Williams 
c/o  Purdue  Laboratory  for 
applied  industrial  control 
102  Michael  Golden 
Purdue  University 
West  Lafayette 
Indiana  47907 
USA 


PUMDUI  I AHOMAIOMY  I OH 
APPt  II  I)  INIHM  HIAI  CON  I lii  >1 
10.'  Mu  hard  i .olden 
PiimIiu*  l Jnivei  sil  y 

Wt'Sl  I .tl.ivi't It*.  Indiana  1 /'to/,  ll'.A 
I I //•!*•.»  H«1 


Please  leply  to: 

Johannes  Reh 

c/o  GPP  Gesellschaft  fiir 

ProzeBrechnerproqram- 

mierung  mbH 

Balanstr.  138/1 

8000  MUnchen  90 

Germany 


Dear  Prof.  Dr.  Williams, 


after  long  internal  considerations  I must  inform  you  that  I am  no  longer 
able  to  act  as  chairman  of  the  LTPL-commi tee. 

As  you  certainly  remember,  I am  sharing  the  responsibilities  for  the 
General  Management  of  GPP  together  with  Dr.  Lichonauer.  The  continuous 
growth  of  GPP  is  continuously  demanding  more  and  more  of  our  available 
time.  Due  to  my  personal  overload  with  work  I have  to  resign  from  the 
LTPL-chairmanship  and,  unfortunately,  cannot  afford  the  time  for  a trip 
to  Purdue  this  fall. 


Please,  explain  my  decision  to  my  commit.ee  fellows.  Mr.  Peter  Flzer, 
with  whom  I am  discussing  possible  al ternativos  for  the  I TPI  work 
continuity,  will  also  explain  my  decision  at  the  workshop. 

I feel  very  much  obliged  to  thank  my  commitee  collegues  for  their 
cooperation  and  I send  my  best  wishes  for  the  further  LTPL  and  workshop  work. 


Very  best  regards 


' I . v ■'  i t jt 

■i  >■  L 


(Johannes  Reh,  Chairman  of  the  LTPL-C.) 


co.  Mr.  Peter  Elzer 

Alliluriinu 


l iMIVt’f  Sll  y 

• nst » iimi’ut  s«x  iety  of  Amenta  through  Data  Handling  and 
International  l ederatlon  for  Information  Procession  as 
r •critiques  technical  Committee,  fc  ii,  Computer 


' (imputations,  Chemical  and  Petroleum  Industiies,  and  Automatic  Control  Divisions 
Woi  kmq  (Troop,  W(i  V»  4.  Common  and  oi  Standardized  Hardware  and  Software 
Applications  in  Technology 
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International  Purdue  Workshop^ 


PURDUE  LABORATORY  FOR 
APPLIED  INDUSTRIAL  CONTROL 
102  Michael  Golden 
Purdue  University 

West  Lafayette.  Indiana  4/90/,  USA 
317/494  842b 

Please  reply  to 


Industrial  Computer  Systems 


INSERT  V 


ANNUAL  REPORT 

VICE-CHAIRMAN  FOR  STANDARDS  COORDINATION 
DR.  T.  J.  HARRISON 
1977  October  A 


A BRIEF  STATUS  REPORT  ON  INTERNATIONAL  STANDARDIZATION  ACTIVITY, 
PRIMARILY  IN  THE  AREAS  OF  LANGUAGES  AND  INTERFACES,  WHICH  ARE 
WITHIN  THE  SCOPE  OF  THE  WORKSHOP 


PRECEDING  PiflB  hi  Any 


a >m,, it  ions  77/99/26 

Purdue  University 

Instrument  Society  of  America  through  Data  Handling  and  Computations,  Chemical  and  Petroleui 
international  Federation  for  Information  Processing  as  Working  Group  WGb-4.  Common  and/* 
niques  of  T ethnical  Committee,  TC-5,  Computer  Applications  in  Technology 
institute  of  Electrical  and  Electronic  Engineering,  Data  Acquisition  and  Control  committee  < >f 
Committee  of  the  Industrial  Application  Society 
I ntnmat innaf  f-  ederatioo  of  Automatic  Control,  Computer  Committee 
National  Research  Council  of  Canada,  Assoc  iate  Committee  of  Automat  i<  ( outrol 
« fimmission  of  the  E uropean  Communities  ((  K.)  through  its  Direr  Incite  ( ieneral  loi  I ncliish  mI  .h 
Japan  f lectmnic  industry  Development  Association  (Jl'IDA)  through  its  II’W  lapan  Cuinmillcr 


I ndustries,  and 
Standardized  l 


Automat  u 
laulware  ar 


C onti ol  Division' 
id  Soft  wait'  I e»  i 


I Industrial  l o » t • nl 


I lllll  ill  ll|l(  ,||  ) 


m 
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Standard  Report 

REAL-TIME  LANGUAGES 

o ACTIVE  PROJECTS 

- INTERNATIONAL  (ISO,  PURDUE  WORKSHOP)  (FORTRAN,  CORAL  EG) 

- UNITED  STATES  (ANSI,  DOD,  ISA)  (FORTRAN,  PL/l,  BASIC 

, . PASCAL-LIKF.) 

- EUROPE  (ECMA,  EEC)  (BASIC,  LTPL) 

- UNITED  KINGDOM  (CORAL  66,  RTL/2) 

- GERMANY  (PEARL) 

o IS0/TCS7/SC5 

- MEETING  1977  NOVEMBER,  THE  HAGUE 

- AGENDA:  PLIP  REPORT,  PL/l,  FORTRAN,  ELEM,  BASIC 

- NO  KNOWN  REAL-TIME  ISSUES 

o IS0/TC97/SC5/WG1  (PLIP) 

- MEETING  1977  NOVEMBER,  LONDON 

- FURTHER  CONSIDERATION  OF  sGl.l,  DSG1.2  FORTRAN  EXT. 

- SHOULD  CORAL  GG  BE  CONSIDERED? 

0 PL/ 1 

- subset/g  - xZJl.Z 

- FREIBURGHOUSE  PROPOSAL 

- PROCESSING  PROPOSALS 

- CHANGE  CUT  OFF  WAS  77/9  MTG . 

- REAL-TIME  EXTENSIONS  - X3J1.4 

- CONSIDERING  WORKING  PAPER:  DOCUMENT/T 

- PROCESSING  PROPOSALS 

- AD  HOC'S  ON  PARTICULAR  STATEMENT 

TJH 

77/09/26 
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Standard  Report 

- ECMA  S sc5  ACTIVITY 

- TClO  PROPOSAL:  INTERACTIVE  DATA  TRANSMISSION 

- Sc5  CONSIDER  PL/l  AT  1077  NOVEMBER  MEETING 

0 2ASIC 

- ECMA/ANSI  - IPW  TC2  AGREEMENT 

- ECMA/ANSI  WORKING  ON  ENHANCEMENTS 

- MINIMAL  BASIC  APPROVAL 

- ANSI  (x3  APPROVED) 

- ECMA  (TC21  APPROVED) 

- ON  SC5  AGENDA:  NN I ~ANS I /ECMA 

- FIPS  PLANNED 

FORTRAN 

- "fortrev" 

- CONCURRENT  X>PUBLIC  REVIEW  CLOSED  77/9/15 

- SOME  NEGATIVE  VOTES 

- COMMENTS:  AOZ  EXTENSIONS;  CZ  DELETIONS;  67  REVISIONS 

- SUBMITTED  TO  97/5 

- S61.1  ISA  EXTENSIONS 

- SUBMITTED  TO  ANSI  BSP. 

- ACCEPTED  BY  97/5/1 

- DSGL2  ISA  EXTENSION'S 

- SUBMITTED  TO  97/5/1 

- READY  FOR  ISA  S&P 

- WILL  SUBMIT  TO  ANSI 

- EXPECT  ISA  APPROVAL  LATE  1977 

- IPW-E  DOCUMENT  REVISED 

TJH 

77/09/26 


T 
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Standard  Report 

o EEC  LTPL  PROJECT 

- PROJECT  LEADER  NOT  SELECTED 

- NO  RECENT  KNOWN  PROGRESS 

o DoD  HOLWG 

- EVALUATION  COMPLETE 

- 4 SPECIFICATION  CONTRACTS 

- Cl  I “HONEYWELL-BULL 

- INTERMETRICS 

- SOFTECH 

- STANFORD  RESEARCH  INSTITUTE 

- ALL  PASCAL-BASED 

- SPEC  (INITIAL  DESIGN)  COMPLETE  1078  (PHASE  1 OF  3) 

o PEARL 

- PRE-STANDARDIZATION  DISCUSSIONS  IN  DIN 

- FULL  DESCRIPTION  DUE  SOON 

o CORAL  66 

- SUBMITTED  TO  97/5/1  (NOT  YET  ACCEPTED) 

- BSI  CONSIDERING  (ALONG  WITH  RTL/2) 


TJH 

77/^9/26 
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Standard  Report 

COMPUTER  SYSTEM  INTERFACES 
o ACTIVE  PROJECTS 

- INTERNATIONAL  (ISO,  IEC,  IPW) 

- UNITED  STATES  (ANSI , ISA,  IEEE) 

o IS0/TCS7/SC13 

- CHANNEL  LEVEL  PROPOSAL  (JAPAN);  CONVERT  TO  TR? 

- WGl:  PROCESS-COMPUTER  INTERFACES 

- DOCUMENT  TECHNICALLY  COMPLETE 

- WG2:  ADMINISTRATION  ~ INACTIVE 

- WC.3:  LOWER-LEVEL  INTERFACES 

- PREPARING  FUNCTIONAL  REQUIREMENTS/APPLICATIONS 

- POINT-TO-POINT  (FULL  DUPLEX) 

- SMALL  COMPUTER  TO  PERIPHERAL  BUS 

- PROCESSOR  SYSTEM  BUS 

o IEC/TCCS/SCC3A/WG6:  INDUSTRIAL  INTER-SUBSYSTEM 

- DOCUMENT  TECHNICALLY  COMPLETE 

- START  "CANDIDATE"  EVALUATION 

o I EC/T C66/WG3 : GPIB 

- BASIC  STANDARD  APPROVED 

- CONNECTOR  BALLOT  NOT  REPORTED 

- CODE-FORMAT  DOCUMENT  TECHNICALLY  COMPLETE 

- "MORE  SERIAL"  BEING  CONSIDERED 

- 200m  proposal  rcjected 

TJH 

77/09/26 
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o CAMAC 

- HAVE  NOT  HEARD  MUCH  LATELY 

- PROBABLY  WILL  BE  ADOPTED  AS  ANS 

0 IPW  ~ TC  5 

- tc5a 

- ADOPTED  FUNC.  REG'TS  ( 66/3) 

- STARTING  EVALUATION 

- tc5e 

- HAS  SPECIFICATION 

o ANSI  X3T9  I/O  INTERFACES 

- x3t9.2  lower  level 

- TWO  SUBGROUPS 

- A = DEVICE  INDEPENDENT 

- B = DEVICE  DEPENDENT 

- NO  SPECIFIC  PROPOSALS 

- x3t9.3  DEVICE  LEVEL 

- EXAMINED  MODIFIED  TAPE  i/F 

- SEEKING  OTHER  CANDIDATES 

- DISK  AND  TAPE  INTEREST 

- CHANNEL  LEVEL  (MAIN  SC) 

- X3  BALLOT 

- FIPS  PUBLISHED  (76/12,  77/8) 

TJH 

77/09/2C 


o ASTM  E31  COMPUTERIZED  LABORATORY  SYSTEMS  (CLS) 

- CONCURRENT  ASTM/ANSI  REVIEW  OF  GUIDELINES 

- e622:  generic  guidelines  for  cls 

- e623:  developing  functional  reo'ts  for  cls 

- e62T:  implementing  cls 

- e62E>:  training  users  of  cls 

- e626:  evaluating  cls 

- eG27:  documenting  cls 

- considering  scope  change:  see  attachment 


TJH 

77/09/26 


TITLE:  OPEN  SYSTEM  INTERCONNECTION 


SCOPE:  INVESTIGATION  OF  THE  NEED  FOR  STANDARDIZATION 

IN  THE  AREA  OF  OPEN  SYSTEMS,  AS  IT  RELATES  TO 
SYSTEM  INTERCONNECTION.  THIS  WILL  INCLUDE  THE 
STUDY  OF  THE  STRUCTURE  AND  NATURE  OF  THE 
STANDARDS  REQUIRED  FOR  EXCHANGE  AND  INTERCHANGE 
OF  USER  TASKS  AND  SYSTEM  CONTROL  AND  STATUS 
INFORMATION.  THIS  WORK  WILL  TAKE  INTO  DUE 
ACCOUNT  THE  ACTIVITIES  OF  TC97/SC6  AND  CCITT 
AND  WILL  BE  BASED  ON  THE  COOPERATION  STATEMENT 
BETWEEN  ISO  AND  CCITT. 

PROGRAMME  Of  WORK 

THE  SUBCOMMITTEE  WILL: 

1.  DEFINE  TERMS  OF  PARTICULAR  CONCERN  TO 
THIS  COMMITTEE. 

2.  PREPARE  A SCHEMATIC  MODEL  FOR  SYSTEM 
ARCHITECTURE  FOR  OPEN  SYSTEM  WORKING, 
IDENTIFYING  AND  SPECIFYING  INTERFACES 

V/HICH  SHOULD  BE  CONSIDERED  FOR  STANDARDIZATION. 

3.  IDENTIFY  THOSE  INTERFACES  FOR  WHICH 
STANDARDS  EXIST  OR  ARE  UNDER  DEVELOPMENT, 

OR  ARE  WITHIN  THE  SCOPE  OF  INTERNATIONAL 
STANDARDIZATION  BODIES  WITHIN  OR  OUTSIDE 
ISO. 

4.  PAY  PARTICULAR  ATTENTION  TO  LIAISON 

WITH  THE  BODIES  CONCERNED  WITH  STANDARDIZATION 
RELATED  TO  ITS  WORK,  AND  WILL  RECOGNIZE 
AND  USE  STANDARDS  PREPARED  BY  SUCH  BODIES. 


1S0/ICS7/SC1E. 


PROGRAMME  OF  WORK  (continued) 

5.  PREPARE  PROPOSALS  FOR  NEW  WORK  ITEMS  FOR 
THE  REMAINING  INTERFACES  FOR  WHICH 
STANDARDIZATION  IS  NEEDED  AND  IS  FEASIBLE. 

6.  DEVELOP  STANDARDS  FOR  THOSE  WORK  ITEMS 
ASSIGNED  TO  IT. 

NOTE:  IT  IS  BELIEVED  THAT  THE  LIAISON  SHOULD  AT  LEAST 

INCLUDE  THE  FOLLOWING’. 


CCITT: 

sc 

7,  3,  17 

TC97: 

sc 

5,  6,  14 

tc95: 

sc 

GC,  46,  194 

I 


1 


1 


i 


...» 


TJ*1 
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PROPOSED  E31  NAME  AND  SCOPE  CHANGE 


Present  Scope 


THE  PROMOTION  OF  KNOWLEDGE,  STIMULATION  OF  RESEARCH, 
STANDARDIZATION  OF  NOMENCLATURE,  AND  RECOMMENDATION  OF 
PROCEDURES  AND  PRACTICES  FOR  DEFINITION,  IMPLEMENTATION, 
DOCUMENTATION,  AND  EVALUATION  OF  COMPUTERIZED  LABORATORY 
SYSTEMS.  THESE  ACTIVITIES  WILL  BE  COORDINATED  WITH  THOSE 
OF  OTHER  RELEVANT  COMMITTEES  OF  ASTM  AND  OTHER  ORGANIZATIONS. 

Proposed  Scope 


THE  PROMOTION  OF  KNOWLEDGE,  STIMULATION  OF  RESEARCH, 
STANDARDIZATION  OF  NOMENCLATURE,  AND  RECOMMENDATION  OF 
PROCEDURES  AND  PRACTICES  FOR  DEFINITION,  IMPLEMENTATION, 
DOCUMENTATION,  AND  EVALUATION  OF  COMPUTERS  AND  COMPUTERIZED 
SYSTEMS.  THESE  ACTIVITIES  WILL  BE  COORDINATED  WITH  THOSE  OF 
OTHER  RELEVANT  COMMITTEES  OF  ASTM  AND  OTHER  ORGANIZATIONS. 

Present  Committee  Title: 


ASTM  COMMITTEE  E“31  ON  COMPUTERIZED  LABORATORY  SYSTEMS 

Proposed  Committee  Title: 


ASTM  COMMITTEE  E"31  ON  COMPUTERS  AND  COMPUTERIZED  SYSTEMS. 


T^H 

77/00/26 


rnmm 


ill  » 
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Mr.  Peter  Elzer 

University  of  Erlangen 

Erlangen,  Germany 

Dr.  Thierry  Lalive  d’Epinay 

Eth 

Zurich,  Switzerland 

The  discussion  was  an  explanation  and  coordination  of  the 
large  amount  of  work  on  Tasking  carried  out  by  the  Industrial 
Real-Time  FORTRAN,  the  Long  Term  Procedural  Language  and  the 
Operating  Systems  Committees  and  published  extensively  in  the 
previous  Minutes  of  the  Workshop. 

Some  recent  references  other  than  those  included  in  this 
present  document  are  as  follows: 

(1)  Caro,  Richard  H. , "Draft  ISA/X56 . 13A" , 

Spring  1977  Minutes,  pp.  144-148. 

(2)  "RT-FORTRAN,  First  Draft  of  the  Purdue  Europe 
Technical  Committee  on  Industrial  Real-Time 
FORTRAN",  Spring  1977  Minutes,  pp . 195-230. 

(3)  Petersen,  Odd,  "Management  of  Parallel  Acti- 
vities in  Real-Time  FORTRAN",  Spring  1977 
Minutes,  pp.  231-274. 

(4)  Timmersfeld,  K.  H. , "Status  Report  Tasking", 
Spring  1977  Minutes,  pp . 337-344. 

(5)  Roberts,  J.  W. , "On  the  American  Redrafting 
of  the  Tasking  Proposals",  Spring  1977 
Minutes,  pp.  407-414. 

(6)  "Up  to  Date  Report,  TC-8",  Spring  Minutes 
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(7)  Hands,  Maxine,  "Tasking",  Fall  1976  Minutes, 
pp.  593-600. 

(8)  Curtis,  R.  L.,  "A  Rationale  and  Proposal  for 
FORTRAN  Extensions  for  Task  Management",  Fall 
1976  Minutes,  pp.  603-621. 

Mr.  Thomas  H.  Lehman  of  the  INTEL  Corporation,  Oak  P.rook, 
Illinois,  presented  a well  illustrated  lecture  on  "PL/M  - A 
High  Level  Programming  Language  for  Microprocessor  Application". 
Mr.  Lehman's  remarks  were  well  appreciated  by  the  attendees  who 
had  many  questions  for  him. 

We  wish  to  express  our  sincere  thanks  to  all  the  tutorial 
speakers  for  a truly  excellent  set  of  presentations,  all  of 
which  were  very  well  received  by  all  the  attendees. 

Man/Machine  Communications 

Included  among  the  papers  of  the  Technical  Committee  on 
Man/Machine  Communications  is  a paper  prepared  by  Messrs.  R. 

R.  Messare,  J.  H.  Laroche  and  D.  Shannon,  all  of  units  of  the 
Exxon  Company.  We  are  very  grateful  to  them  and  their  separate 
companies  for  contributing  this  valuable  work  to  the  TC6  group 
and  to  the  Workshop . 

Reviews  of  Committee  Act ivities 

A major  item  of  discussion  during  this  meeting  of  the 
Workshop  was  a proposal  entitled  A Mechanism  for  Evaluating 
the  Status  and  Need  for  Continued  Existence  of  TPW  Technical 


Committees  (TCs) . The  proposal  as  passed  by  the  Workshop  is 
presented  here  as  Insert  VT . 


-55- 


INSERT  VI 

A MECHANISM  FOR  EVALUATING  THE  STATUS  & NEED  FOR 
CONTINUED  EXISTENCE  OF  IPW  TECHNICAL  COMMITTEES  (TCs) 


Whereas : 

1)  The  personnel  available  for  TC  membership  is  limited, 

2)  New  topics  of  interest  (such  as  Microcomputers) 
continue  to  appear  in  the  application  of  Industrial 
Computers  at  a rate  of  one  every  1 to  2 years, 

3)  A TC  cannot  normally  work  effectively  without  10 
active  members, 

Be  it  RESOLVED: 

That  the  status  of  each  TC  will  be  reviewed  bv  the 

International  Meeting  of  IPW  each  3 years.  This  review 

should  produce  one  of  five  results: 

Rl)  The  TC 1 s current  scope  and  program  are  generally 
useful  and  should  be.  continued. 

R2)  The  TC ' s current  program  could  be  made  more 
generally  useful  by  modifying  the  TC ' s scope 
or  emphasis.  Specific  suggestions  for  these 
modifications  would  be  made. 

R3)  The  work  of  the  TC  is  no  longer  of  general 
interest  and  it  should  be  disbanded  within 
1 year.  Its  scope  mav  be  added  to  an  existing 
TC. 

R4)  The  scope  of  the  TC  should  be  divided.  The 
divided  scope  could  be  added  to  an  existing 
TC  or  a new  TC  could  be  formed. 

R5)  If  a Committee's  purpose,  scope  and  emphasis 
are  deemed  worthwhile  and  consistent  with  the 
overall  goals  of  the  Workshop,  recommendations 
should  be  made  to  the  TC  Chairman  on  ways  of 
improving  attendance. 


The  mechanism  for  conducting  this  review  will  be: 

Ml)  Each  TC  will  be  reviewed  at  least  everv  3 years. 
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INSERT  VI  (Cont.) 


M2)  The  Chairman  of  any  TC,  who  suspects  that  a 
significant  alteration  of  the  TC ' s scope  or 
termination  of  the  TC  is  in  order,  may  request 
an  evaluation  at  the  following  International 
Meeting. 


M3) 


M4) 


If  no  such  requests  are  received,  the  rotation 
will  be  based  on  TC  attendance  at  the  last  two 
International  and  Regional  Workshops  and  will 


be  : 

1978, 

1981 

- TC  9,  TC  2, 

TC  4 

1979, 

1982 

- TC  7 , TC  8 , 

TC  1 

1980, 

1983 

- TC  3,  TC  5, 

TC  6 

If  any 

TC 

requests  earlier 

evaluation , 

exchange  places  with  the  most,  active  (measured 
by  average  attendance  at  the  last  2 International 
Workshops)  TC  scheduled  for  evaluation  that  year. 


K5)  The  Executive  Committee  may  call  for  a review 
of  the  status  of  an  inactive  TC.  This  review 
will  be  in  addition  to  those  scheduled  by  the 
above  rotation. 


M6)  The  Chairman  of  each  TC  scheduled  for  evaluation 
will  submit  to  each  member  of  the  Executive 
Committee  by  September  1 a report  containing: 

6.1)  The  TC's  current  actual  scope  and  areas 
of  primary  interest  and  activity. 

6.2)  A statement  of  the  TC's  specific 
accomplishments  and  the  dates  these  were 
accomplished.  Include  the  last  3 years 
only . 

6.3)  A summary  of  all  International,  Regional 
and  TC  meetings  for  the  last  3 years 
including : 

Dates,  Location 
Number  of  Attendees 
Maior  Topics  Discussed 
Major  Actions  Taken 
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6.4)  The  Chairman's  proposed  future  program 

6.5)  The  Chairman's  recommendation  on  TC  status 

6.6)  Copies  of  the  specific  accomplishments 
listed  in  5.2 

6.7)  Other  relevant  material 


*This  report  will  be  submitted  at  the 
International  Meeting. 


M7)  The  TC  will  present  a tutorial  outlining  a 

significant  phase  of  its  work  at  the  International 
Meeting. 

M8)  The  Executive  Committee  will  formulate  a 

proposed  resolution  on  that  TC's  status  using 
one  of  the  options  (R1  - R5)  outlined  in  this 
resolution . 

M9)  The  Workshop  will  act  on  this  motion.  Amendments 
from  the  floor  will  be  allowed. 


Submitted  by: 


R.  S.  Crowder 

Vice  Chairman,  Planning,  IPW 


10/4/77 


' 
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New  Workshop  Logo 

Insert  VII  presents  the  new  logo  for  the  Workshop  as  pro- 
posed by  Dr.  T.  J.  Harrison,  Chairman  of  the  Ad  Hoc  Letterhead 
Committee.  It  is  a development  of  those  discussions  in  previous 
Workshops.  The  design  was  unanimously  approved  by  the  Workshop 
and  Dr.  Harrison  was  thanked  for  his  efforts  in  preparing  it. 

A copy  of  the  resulting  new  letterhead  is  included  here  as 
Insert  VIII. 

Financial  Report 

Insert  IX  presents  a copy  of  the  Financial  Report  of  the 
Workshop  as  the  date  of  the  present  meeting.  Costs  still  run 
higher  than  meeting  attendance  fee  and  Minutes  sales  income. 
However,  the  Executive  Committee  is  very  reluctant  to  raise 
attendance  fees  and  the  prices  of  individual  Minutes. 

Grant  from  Naval  Air  Systems  Command , U.  S.  Navy 

We  are  very  pleased  to  report  that  the  Naval  Air  Systems 
Command,  U.S.  Navy  has  made  a grant  of  $15,217.00  for  the 
period  of  December  1,  1977  to  November  30,  1978  to  Purdue  Uni- 
versity for  support  of  the  International  Purdue  Workshop  on 
Industrial  Computer  Systems.  The  grant,  which  was  made  through 
the  Office  of  Naval  Research,  will  provide  funds  for  publication 
of  Workshop  Minutes  and  relieve  the  problem  discussed  in  Item  10 
above.  It  will  also  provide  funds  for  the  Workshop  General  Chair- 
man to  attend  the  Regional  Meetings  of  the  Workshop  on  an  alter- 
nate basis.  We  wish  to  thank  the  U.  S.  Navy  most  sincerely  for 
their  interest  in  and  help  to  the  Workshop. 


PRECEDING  FACE  bUANK 
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12.  Cooperation  with  DoD-HOL  Working  Croup 

Insert  X presents  the  wording  of  a Motion  passed  by  the 
Workshop  requesting  a statement  of  formal  cooperation  from 
the  Higher  Level  Languages  Working  Group  of  the  Department  of 
Defense  and  a letter  of  transmittal  of  this  motion  to  Lt . 
Colonel  William  A.  Whitaker,  Chairman  of  the  Working  Group. 

This  Motion  was  necessary  due  to  the  varied  wording  of  the  two 
Motions  passed  last  Spring  by  Purdue  Europe  and  Purdue  Americas 
(see  the  Minutes  1977  Spring  Meeting) . 

13.  Microprocessor  Committee 

Concern  among  the  Workshop  Members  for  the  place  of  the 
microprocessor  in  future  industrial  computer  systems  resulted 
in  the  developed  presentation  and  approval  of  the  following 
motion: 

"That  the  Workshop  establish  an  ad-hoc  Committee 
to  recommend  to  the  Workshop  how  the  Workshop  and 
its  Technical  Committees  should  include  the  in- 
fluence of  microprocessors /microcomputers  in  its 
deliberations.  Such  a recommendation  could  include 
directions  to  existing  committees  and/or  the  estab- 
lishment of  a new  committee  and  the  definition  of 
the  scope  of  such  new  committee." 

Mr.  Yoel  Keiles 
Honeywell.  Inc. 

1100  Virginia  Dr. 

Ft'.  Washington,  PA  19034 
(215)  643-1300 


was  appointed  Chairman  of  this  Committee. 


. a- ' »V-, 


International  Purdue  Workshop' 


PURDUE  LABORATORY  FOR 
APPLIED  INDUSTRIAL  CONTROL 
102  Michael  Golden 
Purdue  University 

West  Lafayette,  Indiana  47907,  USA 
317/494-9425 

Please  reply  to: 


Industrial  Computer  Systems 


Affiliations 

Purdue  University 

instrument  Society  of  America  through  Data  Handling  and  Computations,  Chemical  and  Petroleum  industries,  and  Automatic  Control  Divisions 
International  federation  for  Information  Processing  as  Working  Group  WG5-4.  Common  and/or  Standardized  Hardware  and  Software  Tech- 
niques of  T echnical  Committee,  TC-5,  Computer  Applications  in  T echnology 
institute  of  Electrical  and  Electronic  Engineering.  Data  Acquisition  and  Control  Committee  of  the  Computer  Society,  and  industrial  Conti ol 
Committee  of  the  Indostridi  Application  Society 
I nter national  f-  ederation  of  Automatic  Control,  Computer  Committee 
National  Research  Council  of  Canada,  Associate  Committee  of  Automatic  Control 

Commission  of  the  European  Communities  (CEC)  through  its  Directorate-General  for  Industrial  and  Technological  Affairs 
Japan  Electronic  Industry  Development  Association  (JEIDA)  through  Its  IPW  Japan  Committee 


■ 


L 
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INSERT  IX 

INTERNATIONAL  PURDUE  WORKSHOP  ON  INDUSTRIAL  COMPUTER  SYSTEMS 

WORKSHOP  FISCAL  REPORT 
I NOVEMBER  1976  - 30  SEPTEMBER  1977 


I.  Receipts 


A. 

Attendance  Fees 

*$  6,080.00 

B. 

Sales 

1. 

Minutes,  International  Purdue 
Workshop  on  Industrial 

Computer  Systems 

Accounts  Receivable 

$3099.85 

(876.12) 

2. 

Software  Minutes 

Accounts  Receivable 

1060.00 

(30.00) 

3. 

Hardware  Minutes 

218.00 

4. 

Alcoa  Decks 

-0- 

5. 

Manufacturing  Languages  and 
Software  Systems  Minutes 

Accounts  Receivable 

60.00 

(30.00) 

Subtotal 

4,437.85 

(936.12) 

C. 

DACHOD  Grant 

(1977  Payment  not  yet  received) 

250.00 

250.00 

D. 

IFIP  WG  5.4  Reimbursement  (Received) 

397.80 

E. 

IFIP  WG  5.4  Reimbursement  (Expected) 

682.50 

F. 

Conference  Reimbursement  4th  Annual 

Meeting 

1,347.83 

TOTAL  RECEIPTS 

$12,509.86 

Costs 

A. 

Printing 

1. 

Announcements 

853.61 

2. 

Minutes  International  Purdue 
Workshop  on  Industrial 

Computer  Systems 

5297.83 

— 


PRSCKDINQ  PifQS  MLAMC 


-66- 

INSERT  IX  (Cont.) 

II.  Costs  (continued) 


3. 

Guidelines  Revision 

550.59 

4. 

Letterhead  for  International 
Purdue  Workshop 

177.09 

5. 

Duplicating  Expense  (Other) 

TC  7 Brochure 

101.84 

ARPANET  copies 

100.59 

IRONMAN  copies 

91.24 

Bylaws  copies 

13.42 

Mailing  List  Update  letter 

13.66 

Subtotal 

Mailing  Costs 

1. 

Announcements 

1041.95 

2. 

Minutes  (To  Workshop 

Attendees  & Chairmen  of 

Committees 

67.70 

3. 

Spring  Summary  Mailing 

75.20 

4. 

Miscellaneous  Postage 

383.56 

■ ' 


7,199.87 


Subtotal  1,568.41 


C. 

**Workshop  Meeting  Costs 

2,984.00 

D. 

Secretarial 

2,200.00 

E. 

Telephone,  Telegrams,  etc. 

65.00 

TOTAL  COSTS  $14,017.28 


II.  Net  Loss 


XV.  ***Losses  Brought  Forward 
V.  Total  Loss 


(1,507.42) 

$(23,297.07) 

$(24,804.49) 


♦Attendance  Fees  include  the  Workshop  on  Manufacturing  Languages 
and  Software  Systems. 

♦♦Workshop  Meeting  Costs,  likewise,  include  the  Workshop  on  Manu- 
facturing Languages  and  Software  Systems. 

♦♦♦Losses  Brought  Forward  reflect  a corrected  report  resulting  from 
Conference  remittances  to  the  Workshop  for  the  2nd  and  3rd  American 
Regional  and  Annual  Meetings  in  the  Amount  of  $5038.  Remittance 
for  the  4th  Regional  Meeting  will  be  reflected  in  the  next  fiscal 
report  since  that  figure  has  not  yet  appeared  on  the  books.  Also 
included  is  a $400  remittance  for  the  Workshop  on  Manufacturing 
Languages  and  Software  Systems.  This  accounts  for  a total  on  cost 
recovery  of  $5438. 


NOTE:  The  Purdue  Laboratory  for  Applied  Industrial  Control  has 

completed  the  work  for  Contract  Number  N00014-76-C-0732 
from  the  Office  of  Naval  Research  and  has  expended  the  sum 
of  the  Grant  which  was  $27,800. 

This  work  covered  the  reprint  of  the  LTPL-E  Language  Comparison 
• Study,  as  well  as  providing  an  Index  to  the  Minutes  of  the  Inter' 1 

Purdue  Workshop,  a composite  descriptive  document  of  the  Workshop 
(Report  No.  77),  and  a collection  of  the  major  definitive  docu- 
ments of  the  Workshop  in  six  parts. 

These  publications  are  available  upon  request. 


I 
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PURDUE  LABORATORY  FOR 
APPLIED  INDUSTRIAL  CONTROL 
10?  Micharl  Golden 
Put  duo  University 

West  Lafayette.  Indiana  4/90/  USA 
317/494  8475 

Please  reply  to 

Abo\  e 


- 


November  6,  1 °7  7 


Et.  Col.  William  A.  Whitaker,  Chairman 
D0D-H0E  Working  Croup 

Defense  Advanced  Research  Projects  Agency 
1400  Wilson  Rlvd. 

Arlington,  Virginia  22209 

Dear  Colonel  Whittaker: 

As  a follow-up  to  my  letter  of  June  27,  1077,  I am  happv  to 
transmit  officially  to  you  a Resolution  passed  by  the  Fifth 
International  Meeting  of  the  International  Purdue  Workshop 
on  Industrial  Computer  Systems  on  Tuesday,  October  4,  1077. 
We  are  happy  that  you  could  be  with  us  on  that  occasion 
and  hear  for  vourself  the  sentiments  of  our  group  concern- 
ing the  intent  of  this  Resolution  and  our  sincere  desire  to 
continue,  as  in  the  past,  the  excellent  cooperation  between 
our  two  groups  as  called  for  in  the  Resolution.  The  Resolu- 
tion as  passed  is  given  in  Attachment  I. 

As  you  know  our  European  Regional  Organization  passed  the 
form  of  this  Resolution  given  in  Attachment  II  at  their 
Meeting  at  Ispra  in  Italy,  on  March  31,  1977.  It  is  identi- 
cal to  the  other  except  for  the  Addendum  calling  for  action 
to  be  originated  by  the  American  Regional  Organization  of 
the  Workshop.  In  response  to  this  request  from  their 
European  colleagues,  the  latter  region  passed  a different 
Resolution  on  April  21,  1Q77  (Attachment  III)  which  was 
transmitted  to  you  with  my  letter  of  June  27,  1977. 

because  of  the  difference  in  wording  of  the  two  Resolutions, 
we  felt  it  necessary  to  pass  the  original  Resolution  in 
the  International  Meeting  hence  our  action  on  October  4. 


► * 1 1*  due  l InivPt  m t y 

i "s*  Mi'Mi-M  t ■..»«  i»'t  v Of  A met  mm  through  Data  » land  ting  and  t ompu tat  ions,  <'  hciun  at  ami  i vtr  n 
Intm  national  » migration  tor  Information  Pm.essmg  as  Working  to. tup  W<;*.  A i ..innton  an 
-mjurs  Of  Technical  < oinmittep.  It  •»,  t mnputer  Appln  atrons  in  t c<  hnolngy 
Institute  of  I tPitncal  ami  I Iftrlmnn  I rnjinopiing,  Data  Acquisition  and  t nntiol  t nmrnith'n 
t nnumtter  of  the  Industrial  Appln  ation  So«  iPtv 
i liter  national  l Pdar  ation  of  Automatic  Control,  < omputer  t omnuttee 
Nati.Mia  RPspari  t!  Council  of  Canada,  As\m  late  t mninittee  of  Automaln  i , t r . * t 


• m Industtie*,  and  Automaln  t ontini  |> 
" '•taudai  di.-rtl  llaidwate  and  Softwao 

tin-  i .'inpiili  i *.oiri'»v  , mil  IfUfustr ».ri  t 
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INSERT  X (Cont.) 

Lt.  Col.  William  A.  Whitaker 
November  4,  1977 
Page  Two 


As  I stated  in  my  previous  letter  and  also  above,  we  of  the 
Workshop  are  very  appreciative  of  the  cooperation  which  has 
taken  place  between  your  DOD-HOL  Working  Group  and  our  LTPL 
Committee,  particularly  its  American  and  European  Branches, 
LTPL-A  and  LTPL-E.  We  hope  very  much  that  this  can  continue. 
The  purpose  of  our  Resolution  therefore  is  to  start  any 
necessary  procedures  involved  in  putting  such  cooperation 
on  an  official  basis  so  that  it  will  be  sure  to  occur 
regardless  of  any  change  in  personnel  assignment,  etc.,  on 
either  side. 

We  look  forward  to  hearing  from  you  concerning  this  and  to 
seeing  you  at  our  future  meetings.  Thank  you  very  much  for 
your  consideration. 

Best  wishes. 


Sincerely , 


Theodore  J.A/illiams 
General  Chairman 


T JW : mrw 


Enel.  (3) 


Mr. 

Barry 

DeR oze 

Mr. 

J. 

F.  Auvaerter 

Mr . 

James 

S.  Campbell 

Mr . 

A. 

Lai 

Dr. 

Walter  Beam 

Mr . 

R. 

G.  Hand 

Mr. 

W. 

E. 

Vannah 

Mr . 

R. 

M.  Brown 

Mr . 

W. 

G. 

Madison 

Mr . 

J. 

E.  Peyton 

Mr. 

D. 

L. 

Shoemaker 

American  Region  Executive 

Committee 

Mr . 

A. 

P. 

McCaulev 

European  Region  Executive 

Commi ttee 

Mr . 

B. 

A. 

Zempolich 

International  Executive  Committee 
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ATTACHMENT  I 
COOPERATION  BETWEEN  t_H_e 

HIGHER  ORDER  LANGUAGES  WORKING  GROUP-DEPARTMENT  OF  DEFENSE 

AND  THE 

INTERNATIONAL  PURDUE  WORKSHOP  Oil  INDUSTRIAL  COMPUTER  SYSTEMS 

RESOLVED:  That  in  the  interest  of  fostering  the  development 

and  standardization  of  higher  level  languages  for  use  with 
real-time,  on-line,  sensor-based  computer  systems,  the 
international  Purdue  Workshop  on  Industrial  Computer  Sys- 
tems through  its  International  organization  and  its  Regional 
Branches  reiterates  its  desires  to  cooperate  fully  with  the 
Higher  Order  Languages  Working  Group  of  the  Department  of 
Defense  of  the  United  States  (1IOL-DOD)  in  the  development 
of  such  a language. 

The  Workshop  participants  request  a similar  formal  ex- 
pression of  cooperation  on  the  part  of  the  HOL-DOD  Working, 
Group.  This  is  to  facilitate  the  establishment  of  the 
mechanisms  for  implementing  the  necessary  coordination  of 
the  work  of  the  two  groups.  It  is  necessary  because  of 
the  several  governmental  and  international  bodies  who  sup- 
ply funding  for  the  several  individuals  and  groups  who  will 
be  involved  in  this  cooperative  effort. 

The  cooperative  work  discussed  here  will  be  carried  out 
mainly  by  the  Long  Term  Procedural  Language  Committee  (I..TPL-C) 
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ATTACHMENT  I (Cont:.) 

of  the  Workshop  and  its  three  regional  branches,  LTPL-A, 
LTPL-E,  and  LTPT,-J  for  America,  Europe,  and  Japan  respec- 
tively. Other  committees  of  the  Workshop  will  be  involved 
also . 


Passed  by  the  Fifth  International  Meeting  of  the  International 
Purdue  Workshop  on  Industrial  Computer  Systems,  October  4,  1977, 
Purdue  University,  West  Lafavette,  Indiana. 
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14.  Elections 

Mr.  Richard  H.  Caro  as  Chairman  of  the  American  Region 
served  as  Chairman  of  the  Nominations  Committee.  He  was 
joined  by  Mr.  Nicolas  Malagardis,  Chairman,  Furdue  Europe, 
and  Professor  Mitsuru  Terao,  Chairman,  Purdue  Japan.  The 
proposed  slate,  unanimously  elected,  was  as  follows: 


TC  1,  Chairman,  FORTRAN  Committee 

Dr.  Matthew  Cordon-Clark 
Scientific  Associate 
Technology  Center 
Scott  Paper  Company 
Scott  Plaza  No.  3 
Philadelphia,  PA  19113 


TC  2,  Chairman,  Industrial  BASIC  Committee 

Professor  Cordon  Bull 
Dartmouth  College 
Krewit  Computation  Center 
Hanover,  NH  03755 


TC  3,  Chairman,  Long  Term  Procedural  Languages 
Committee 

Dr.  Merritt  E.  Adams 
Dept.  7103 

Western  Electric  Company 
4513  Western  Avenue 
Lisle,  IL  60532 


TC  4,  Chairman,  Problem-Oriented  Languages 
Committee 

Dr.  Hans  Windauer 
Mathematischer  Beratungs  und 
Programmierungsdienst  GMBH  - 
Semerteichstr . 47 
4600  Dortmund 


FEDERAL  REPUBLIC  OF  GERMANY 
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TC  5,  Chairman,  Interfaces  and  Data 
Transmission  Committee 

Dr.  R.  Warren  Gellie 

Control  Systems  Lab  Bldg.  M 3 

National  Research  Council/Canada 

Montreal  Road 

Ottawa,  Ontario 

CANADA  KIA  0R6 


TC  6,  Chairman  Man/Machine  Communications 
Committee 

Mr.  Robert  F.  Carroll 
Manager,  Systems  Engineering 
B.  F.  Goodrich  Chemical  Company 
6100  Oak  Tree  Boulevard 
Cleveland,  Ohio  44131 


TC  7,  Chairman,  System  Reliability,  Safety  and 
Security  Committee 

Mr.  Roy  W.  Yunker 
Director,  Process  Control 
PPG  Industries 
#1  Gateway  Bldg. 

Pittsburgh,  PA  15222 


TC  8,  Chairman,  Feal-Time  Operating  Systems 
Committee 

Dr.  Thierry  Lalive  d"Epinay 
Hybridrechnen centrum  do  ET1I 
Voltastrasse  18 
CH-8044  Zurich 
SWITZERLAND 


Vice  Chairman  for  Planning 

Mr.  Robert  S.  Crowder,  Jr. 

Senior  Engineering  Associate 

Engineering  Physics  Laboratory  - Bldg.  357 

E.  I.  duPont  deNemours  & Co. 

Wilmington,  DE  19898 


Vice  Chairman  for  Standards  Coordination 

Dr.  Thomas  J.  Harrison 
Senior  Engineer 
General  Systems  Division 
IBM  Corporation  22R031 
P.  0.  Box  1328 
Boca  Raton,  FL  33432 


Dr.  Theodore  J.  Williams 
Purdue  Laboratory  for  Applied 
Industrial  Control 
102  Michael  Golden 
Purdue  University 
West  Lafayette,  Indiana  47907 

15.  Future  Meetings 

The  Spring  Regional  Meeting  of  the  International 
Purdue  Workshop  on  Industrial  Computer  Systems  will  take 
place  as  follows: 

Purdue  Europe 

April  4-7,  1978  (4  days) 

ETH,  Zurich,  Switzerland 

Purdue  Americas 

April  10-12,  1978  (3  days) 

Purdue  University 
West  Lafayette,  Indiana 

Purdue  Japan 

End  of  June  - First  of  July,  1978 
JEIDA 

Tokyo,  Japan 

The  Sixth  Annual  Meeting  will  take  place  as  follows: 
October  9-12,  1978  (4  days) 

Purdue  University 

West  Lafayette,  Indiana  USA 
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CHAPTER  II 

REPORTS  OF  THE 

INDUSTRIAL  REAL-TIME  FORTRAN  COMMITTEE 


The  following  documents  are  included  here: 

1.  Minutes  of  the  Meetings  of  October  3-6  of  TCl-C. 

2.  Correspondence  between  M.  Gordon-Clark  and  G.  Heller  re 


collaboration  of  TC1-A  and  TC1-E. 
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INTERNATIONAL  PURDUE  WORKSHOP  ON 
INDUSTRIAL  COMPUTER  SYSTEMS 


PURDUE  LABORATORY  FOR 
APPLIED  INDUSTRIAL  CONTROL 
102  Michael  Golden 
Purdue  University 

West  Lafayette.  Indiana  4 790  7,  USA 
31  7/494  8425 


NOV  -31977 


Please  reply  to: 


October  14,  1977 
Scott  Paper  Company 
Scott  Plaza  III 
Philadelphia,  Pa.  19113 


Minutes  of  the  Joint  Meeting  of  the  International  Purdue  Workshop  FORTRAN 
Comnittee  (TCI)  and  ISA  SP61  Committee  on  Industrial  FORTRAN  held  at  Purdue 
University,  West  Lafayette,  Indiana,  October  3rd  to  6th,  1977. 

The  following  were  present: 

Matthew  R.  Gordcn-Clark  - Scott  Paper  (Chairman) 

Kamal  Bitas  - Mod comp 

Richard  Caro  - Foxboro 

Nicholas  Malagardis  - IRIA  France 

Odd  Pettersen  - Norwegian  Institute  of  Technology,  Norway 
Mary  Pickens  - General  Motors 
Gaston  Thibaut  - Alcan,  Canada 
Edward  Wilkens  - Interdata 

Apologies  for  absence  were  received  from  Rick  Signor,  Maxine  Hands,  and 
Guenter  Heller  (Chairman  of  ICI-E) . 

The  agenda  was  agreed  upon  as  follows: 

S61-1  - 1976 

S61-2  - 1977 

ANSI  X3J3  FORTRAN/ 7 7 

ISO/IC97/SC5/WG1 

Report  on  Activities  of  TCI-A 

Report  on  Activities  of  TCl-E 

There  was  no  report  on  Td-J  activities  as  there  was  no  Japanese  member  present. 
S61-1-  1976 

Matthew  Gordon-Clark  reported  that  ISA  S61-1-1976  had  been  sumitted  to  ANSI 
for  approval  as  an  American  National  Standard.  The  only  comments  which  were 
procedural  rather  than  technical,  had  been  resolved  and  it  was  likely  to  be 
approved  by  ANSI  in  the  near  future.  
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Affiliations 

Purdue  University 

instrument  Society  of  America  throuQh  Data  Handling  and  Computations,  chemical  and  Petroleum  Industries,  and  Automatic  Control  Divisions 
international  Federation  for  information  Processing  as  Workmq  Group.  WG  b 4 Common  and/or  Standardized  Hardware  and  Software 
Techniques  of  Technical  Committee.  T b.  Computer  Applications  in  Technology 


Draft  S 6 1—2— 1977 


Matthew  Gordon-Clark  reported  that  this  document  had  not  yet  been  sent 
out  by  the  ISA  Standards  and  Practices  Board  for  a letter  ballot  because  the 
Board  had  asked  for  additional  documentat ion.  It  was  expected  that  a approval 
would  come  before  the  end  of  the  year. 


ANSI  X3J3  FORTRAN/77 

Richard  Caro  reported  that  the  FORTRAN/ 77  document  had  been  submitted  to 
ANSI  for  approval  as  a standard  and  is  expected  to  become  ANS  X3. 9-1977, 
replacing  X3. 9-1966,  X3. 10-1966  (Basic  FORTRAN)  will  be  dropped  but  included 
in  X3. 9-1977  is  a FORTRAN  subset.  Ln  addition,  FORTRAN/77  will  be  presented 
to  TSO/TC97/SC5  to  become  an  ISO  standard  replacing  ISO  R1539-1972. 

Rick  Signor  was  not  present  because  lie  was  attending  the  X3J3  meeting  to 
consider  extensions  to  FORTRAN  in  areas  such  as  process  control,  typesetting, 
numerical  control,  time  sharing,  and  data  base  management, 

1 

ISO/TC97/SC5/WG1  (PL1P) 

Matthew  Gordon-Clark  reported  on  the  recent  papers  on  FORTRAN  from  AFNOR 
which  consisted  of  additional  areas  for  FORTRAN  standardization.  It  was 
possible  that  the  FLIP  meeting  in  London  will  recommend  that  ISA  S61-1-1976 
and  draft  ISA  S61-2-1977  be  sent  to  SC5  tor  a vote  to  become  ISO  standards. 


Activities  of  TC1-A 

The  TC1-A  committee  has  met  in  San  Jose  in  January  1977,  Purdue  in  April 
1977  and  Foxboro  in  June  1977,  The  San  Jose  meeting  was  devoted  to  answering 
the  comments  on  draft  S61-2-1977.  The  other  meetings  were  concerned  with 
tasking  and  the  choice  of  features  for  inclusions  in  S61-3.  A preliminary 
draft  document  was  prepared  for  the  committee  for  the  International  meeting 
at  Purdue. 


Activities  of  TC1-E 

The  TC1-E  committee  has  met  in  Brussels  in  January  and  in  August  and  in 
Ispra,  Italy  in  March  1977.  In  these  meetings  the  committee  had  developed 
and  refined  a document  describing  industrial  FORTRAN  in  its  totality. 

This  document  is  a superset  of  S61. 1-1976,  draft  S61-2-1977  and  the  pre- 
liminary ideas  on  S61-3. 
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S61-3  Proposals 

The  majority  of  the  committee's  time  was  spent  in  defining  the  technical 
contents  of  S61-3.  Two  documents  were*  studied  in  detail  - TC1-E  FORTRAN 
section  2 (called  E below)  .and  draft  S61-3  by  Richard  Caro  and  Matthew 
Cordon-Clark  (called  A below)  to  determine  significant  differences.  The 
following  differences  in  terminology  and  intent  were  found: 

1.  The  STOP  transition  was  inadvertently  left  oi  l Lite  state  diagram 
in  A,  also  page  1 of  A on  scope  was  not  included  in  the  copies 
distributed  to  committee  members. 

2.  The  terms  "task"  in  A was  not  the  same  as  "activity"  in  E. 

A task  in  A existed  only  as  long  as  its  virtual  processor  existed 
so  that  several  independent  (non-cyclic)  invocations  of  an  executable 
program  would  constitute  different  tasks.  In  the  F.  document  these 
executions  would  constitue  a single  activity. 

3.  Document  A does  not  include  the  KILL  and  CREATE  calls  in  document  E. 
In  document  E,  these  calls  do  not  imply  linking, but  are  used  to 
associate  an  activity  name  to  an  executable  program. 

4.  Document  A has  a generalized  initiation  call  - SKED  - All  document  E 
calls  are  special  cases  of  SKED  and  it  was  expected  that  all  calls 
in  E would  be  explicitly  defined  in  later  versions  of  A.  Similar 
comment  applies  to  DSKED  and  DELAY. 

5.  The  term  "event  mark"  in  document  A was  thought  of  as  a mechanism 
for  describing  process  interrupts  as  they  are  typically  used  in 
process  programs  for  such  purposes  as  task  activation,  task 
resumption  and  for  counting  purposes. 

6.  The  term  "semaphore"  in  document  E was  intended  to  provide  a 
mechanism  for  a programmer  to  be  able  to  construct  critical 
regions,  control  the  sharing  of  resources,  and  the  interrelation- 
ship between  cooperating  activities. 

7.  Definitions  need  to  be  improved  in  both  documents.  Among  the  terms 
that  need  good  definitions  are  executable  program,  event  mark, 
activity  and  task.  It  is  necessary  to  check  existing  glossaries  to 
ensure  that  definitions  do  not  depart  from  existing  standards. 

8.  Both  documents  did  not  consider  the  problems  of  critical  regions  or 
inter-task  communication.  The  former  can  not  be  solved  in  any 
adequate  manner  without  a BLOCK  structure,  and  the  latter  can  be 
done  by  files  and  read/write  using  S61-2.  Also  general  exception 
handling  cannot  be  provided  consistent  with  the  rules  of  FORTRAN. 
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The  conmittee  investigated  the  similarities  and  differences  between  the  event 
mark  and  the  semaphore.  It  was  established  that  the  two  desired  results  could 
be  achieved  by  one  concept  called  an  event  mark  with  the  following  functions 
and  properties: 

Event  mark  is  a non-negative  integer. 

SETEM  increments  an  event  mark  by  one 

CLREM  decrements  an  event  mark  by  one 

TESTEM  a Boolean  function,  true  if  the  event  mark  is  non-zero 

false  if  zero. 

1RESEM  sets  an  event  mark  to  any  positive  integer 
RDSEM  re3ils  the  positive  integer  value  of  an  event  mark. 

In  the  functions  of  SKED,  DSKED,  DELAY,  if  an  event  mark  is  used  to  initiate 
the  function,  the  event  mark  would  be  automatically  decremented. 

The  changes  to  document  A are  the  addition  of  PRESEM  and  RDSEM,  and  the 
necessity  for  automatical ly  decrementing  the  event  mark  in  SKED,  DSKED,  DELAY. 

The  semaphore  functions  in  document  E are  performed  as  follows: 


SIGNAL 

WAITS 

AWAIT 


by  SETEM 

by  DELAY  with  S*3  (or  S**4  which  provides  a time  out 
to  avoid  dead  lock) 

by  DELAY 


provided  the  "j"  parameter  was  made  equal  to  1.  This  restriction  was  considered 
reasonable  as  the  possibility  of  "j"  being  different  than  one  was  only  a recent 
addition  to  document  E.  Odd  Pettersen  agreed  to  discuss  this  point  with  TCl-E. 
If  it  is  desired  to  test  an  event  nark  to  determine  its  value  (such  a test  may 
be  desired  if  an  event  nark  is  used  to  control  a message  buffer)  this  can  be 
achieved  as  follows: 


If  (RDSEM  (I).  I/V.  VAL)  THEN 


This  unified  description  was  considered  to  be  most  satisfactory  as  it 
provided  capability  both  for  the  process  engineer  in  terms  he  could  understand 
as  interrupts  and  for  the  system  designer  who  required  a semaphore  for  system 
control. 


General  Considerations 

Matthew  Gordon-Clark,  Nick  Malagardis  and  Odd  Pettersen  discussed  the 
possible  mechanisms  for  TCl-E  to  perstie  the  standardization  of  the  new  ideas 
included  in  TCl-E  FORTRAN  document  especially  in  areas  of  process  input/output, 
date  and  time,  and  files.  It  was  agreed  that  TCl-A,  though  its  alter  ego 
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SP61,  would  develop  a tasking  standard  S61-3.  l’Cl-E  could  make  its  additions 
into  an  S61-4  for  standardization  by  a European  committee  through  ISA  (Tom 
Harrison  can  see  no  reason  for  this  not  to  work  but  it  would  be  most  unusual) ; 
it  could  apply  directly  to  the  ISO  via  TC97/SC5/W61;  it  could  go  to  a 
European  national  standards  body;  or  it  could  use  some  route  through  the  CEC 
in  Brussels.  It  was  agreed  that  a procedure  for  standardization  of  work 
developed  by  the  TPW  in  Europe  must  be  developed.  Nick  Malagardis  will 
recomnend  an  approach. 


. 


IRONMAN 

The  committee  met  in  joint  session  with  the  LTPL  committee  to  consider 
further  work  on  the  DoD  IRONMAN  document.  It  was  decided  to  provide  a list 
of  relevant  papers  from  all  sources.  LTPL-E,  LTPL-A  and  FORTRAN  committee  were 
asked  to  provide  copies  of  these  documents  together  with  a brief  explanation 
of  their  contents  and  relevance  to  IRONMAN  by  the  joint  meeting  with  LTPL-A 
scheduled  for  San  Diego  in  January.  It  is  important  that  these  documents  be 
ready  by  that  date  if  the  IPW  wishes  to  influence  the  DoD  choice  of  con- 
tractors for  the  next  phase  of  their  project. 

Presentation 

A presentation  on  tasking  was  made  to  the  entire  workshop  by 

Matthew  Gordon-Clark,  Richard  Caro  and  Odd  Pettersen  of  TCI 
Peter  Elzer  and  Alex  Arthur  of  TC3 
Thierry  Lalive  D'Epinay  of  TC8. 

This  discussion  on  the  total  tasking  effort  of  the  IPW  was  well  received  and 
all  the  presenters  are  thanked  for  their  efforts. 

Also  the  present  position  of  the  FORTRAN  work  on  tasking  was  discussed 
with  the  LTPL  committee.  The  LTPL  committee  agreed  to  provide  the  FORTRAN 
committee  with  a copy  of  their  document  on  tasking  as  soon  as  it  was  ready. 

Actions 

The  following  actions  were  assigned: 

Complete  submission  of  S61-2-1977  - Matthew  Gordon-Clark 

Report  to  TC-l-E  on  decisions  on  S61-3  and  indicate  agreement  or 
disagreement  - Odd  Pettersep 
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Put  S61-3  corrected  on  word  processing  system  and  issue  revised 
document  - Richard  Caro 

Propose  mechanism  for  IIV-E  standardization  - Nicholas  Malagardis 
Prepare  comments  and  examples  for  S61-3  - All 
Provide  new  or  better  definitions  for  S61-3  - All 

Collect  FORTRAN  documents  for  IRONMAN  review  - Matthew  Gordon-Clark 


Future  Meetings 

TCl-A/lSA  SP61 

Santa  Ana 

January  3rd,  1978 

San  Diego 

(jointly  with  LTPL-A) 

January  4th/5th,  1978 

Purdue 

April  llth-13th,  1978 

Philadelphia 

May /June  1978 

TCl-E 


Brussels 

Zurich 


January  3rd-5th,  1978 
April  3rd-6th,  1978 


Matthew  R.  Gordon-Clark 

Chairman  of  IPW  FORTRAN  Committee  (TCI) 

and  ISA  SP61  Conmittee 


1 
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Chairman  of  the  International  Purdue  Workshop 

Dr.  Th.  J.  Harrison 
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Mr.  M.  R.  Gordon-Clark 
Chairman  of  the  International  and  the 
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t ll 

Concern:  5L  International  meeting  of  the  International 

Purdue  Workshop,  Oct.  3-6,  1977. 

Paper  S61-3  on  tasking  in  RT-FORTRAN. 

Gentlemen : 

Many  thanks  for  the  announcement  and  agenda  of  the  IPW  meeting, 
which  I received  today.  I regret  very  much  not  being  able  to 
attend  the  IPW  meeting  this  year.  Therefore  I have  to  make  my 
comments  by  a letter. 

Let  me  first  cite  the  announcement  and  agenda  of  the  meeting, 
pages  10  and  11: 

"The  FORTRAN  Committee  (TC-1)  will  devote  most  of  its  time  to 
consideration  of  S61-3.  In  particular,  the  complete  technical 
contents  of  this  document  will  be  decided  on  at  this  meeting . 

The  details  of  the  actual  document  will  not  be  decided  at  the 
meeting  but  no  new  ideas  or  features  will  be  included  after 

this  meeting Any  ideas  submitted  to  the  committee  after 

this  meeting  will  be  deferred  until  another  standard  is  developed 
or  until  the  current  standards  are  reviewed  (this  occurs  every 
f i ve  (5)  years) . 

IF  YOU  WISH  TO  INFLUENCE  THE  CONTENTS  OF  THE  FORTRAN  STANDARD 
'\  TASKING,  BE  SURE  TO  COME  TO  THIS  MEETING. 

HIS  IS  YOUR  LAST  CHANCE." 
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Prof.  Dr.  G.  Heller 
FHT  Mannheim 
Speyerer  Strasse  A 
D 68  Mannheim  1 
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The  paper  S61-3  to  be  decided  on  has  not  vet  been  received  by  our 
committee.  We  have  only  got  from  Mr.  Gordon- Clark  two  papers 
referring  to  S61-3: 

(1)  A proposal  of  Mr.  Caro  to  S61-3  of  April  13,  1977  and 

(2)  a short  table  of  contents  of  the  intended  paper  S61-3 
in  the  minutes  of  June  22,  1977. 

In  (1)  four  calls  for  the  tasking  are  proposed,  which  are  complete- 
ly different  from  the  calls  for  tasking  already  standardized  in 
S61-1.  The  table  of  contents  mentioned  above  show  that  the  paper 
(1)  refers  to  a part  of  S61-3  only.  Besides  from  the  more  in- 
official paper  (1)  of  Mr.  Caro  to  the  present  official  paper  S61-3 
there  have  been  two  meetings  of  the  American  committee  in  between. 
Thus  our  committee  has  nothing  but  vague  ideas  what  might  be  t lu- 
te clinical  content  of  S61-3. 

I'm  sorry  to  say  the  following:  Our  committee  cannot  agree  t o fix 
the  technical  contents  of  the  standard  Sol-3  at  the  IPW  meeting 
as  we  do  not  know  this  standard  at  present  and  did  not  have  the 
chance  to  discuss  it  and  eventually  to  recommend  improvements. 

I therefore  propose  the  following  motion: 

The  International  Purdue  Workshop  may  not  decide  at  its 
5th  meeting,  on  the  technical  contents  of  S61-3. 

If  this  motion  cannot  be  accepted  for  any  reason  I ask 
Dr.  Harrison,  Vice  Chairman  for  Standards,  to  support  our  aim 
in  accordance  with  article  VI,  section  2,  point  b,  of  the  bylaws 
as  the  technical  contents  of  Sbl-3  are  not  adequately  reviewed 
by  all  who  are  substantially  concerned. 


Yours  sincerely 


* 


VWSjdvd  ■ 


Chairman  of  Purdue  Europe 
TC  l on  Industrial  Real-Time 
FORTRAN 


0 Mr.  K.  Thompson,  CEC 

Mr.  N.  Malagardis,  Chairman  of  Purdue  Europe 

All  chairmen  of  the  Purdue  Europe  technical  committees 

Members  of  Purdue  Europe  TC  1 
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Please  reply  to  SEP  2 7 W 

SCOTT  PAPER  COMPANY 
Scott  Plaza  III 
Philadelphia,  Pa.  19113 

September  21,  1977 


Professor  G.  Heller 
FI  IT  Mannheim 
Speycrer  Strauss  4 
D 68  Mannheim 
West  Germany 

Dear  Professor  Heller: 

Thank  you  very  much  for  your  letter  of  September  6,  1977.  I 
believe  we  have  a misunderstanding  of  the  term  "technical  contents"  used 
in  my  notice  of  the  agenda  for  the  FORTRAN  Committee  Meeting  of  the 
International  Purdue  Workshop  and  I assure  you  there  is  no  intent  to 
force  a standard  into  existence  without  widespread  public  review;  indeed 
the  appropriate  standards  management  boards,  such  as  ISA  Standards  and 
Practices  Board,  will  not  approve  any  document  without  a public  review. 

The  term  "technical  content"  was  used  to  distinguish  the 
actual  technical  scope  of  a standard  from  the  detailed  description  and 
accurate  wording  of  the  standard.  This  definition  of  the  technical  scope 
is  necessary  so  that  attention  can  be  given  to  the  actual  writing  of  the 
standard.  Certainly  new  ideas  may  arise  after  the  technical  contents  have 
been  defined  but  to  ensure  that  standards  are  written  in  reasonable  time 
such  new  ideas  arc  postponed  until  the  next  revision  or  the  next  addition 
to  the  standard.  As  an  example  the  new  ANSI  FORT RAN  does  not  include 
a bit  data  type  and  the  committee  did  not  deny  the  usefulness  of  such  a 
concept,  but  the  committee  had  made  a decision  to  exclude  bit  data  types 
from  the  technical  content  of  the  standard.  If  such  action  is  not  taken, 
the  detailed  description  and  writing  of  a standard  will  never  begin. 


At  f iii, if i *n\ 

Purduf  U»iv**»%»lv 

Inst  hi  m<»n|  Soi  t v < >f  Ament  a t hr  011*11’  l tala  * tan  tiling  anti  t omoutat  mm.  (Hrmit.ii  and  1’etrotrum  In.iwslnes,  ami  Automata  t out  ml  (hvumm 
international  federation  for  Information  Processing  as  WoAinq  Uruup.  W(i  V4  Common  and/or  Standardized  Hardware  and  Software 
techniques  of  ‘echmcai  Committee.  TCS,  Computer  Applications  in  Technology 


-88- 


■ • ~ 


Professor  G.  Heller 
September  21,  1977 
Pa^e  2 . 


As  far  as  S61-3  is  concerned,  tlie  central  technical  contents 
are  not  the  details  of  the  tasking  calls  --  I agree  that  the  papers  of 
Dick  Caro  arc  only  preliminary  ideas  and  in  no  way  represent  a finished 
standard,  indeed  the  definitions  in  the  TPW  Europe  document  are  more 
complete  --  hut  whether  the  subject  of  critical  regions  and  of  inter- 
task communication  of  data  he  included,  and  whether  the  system  features 
in  KILL  and  CREATE  should  he  included.  When  a decision  is  taken  on  the 
technical  content  of  S61-3,  the  detailed  description  of  the  required 
subroutines  and  their  associated  parameters  can  begin.  It  is  my  intent 
to  resolve  these  issues  in  October  at  Purdue. 

The  actual  standard  document  will  take  several  meetings  to 
prepare.  My  earliest  date  for  a document  which  I could  ask  ISA  to 
distribute  for  public  review  is  July  1978,  which  is  after  three  more 
Committee  Meetings  (San  Diego  in  January,  Purdue  in  April,  one  on  the 
East  Coast  probably  Philadelphia  in  June).  This  could  easily  be  an 
optimistic  schedule.  1 also  anticipate  extensive  comments  on  this  first 
public  review  and  a significant  rewrite  ol  the  document. 

There  will  be  technical  items  that  could  be  included  in 
Industrial  FORTRAN  that  will  be  not  in  S 6 1 — l , S61-2,  Sbl-3.  The  French 
standards  organization,  AFNOR,  has  submitted  an  interesting  paper  on 
extensions  to  FORTRAN  for  industrial  purposes  to  Ihe  working  group  of 
the  ISO  ( ISO/TC97/SC')/WG- l ) and  have  been  requested  to  present  proposals 
on  these  ideas  as  a standard.  When  the  technical  content  of  S61-3  is 
established,  members  of  the  FORTRAN  Committee  of  the  Ills’  may  wish  to 
embark  on  the  development  of  additional  features  in  parallel  with  the 
actual  writing  of  Sbl-3  as  occurred  with  the  development  of  Sbl-3  while 
S61-2  was  being  written.  This  method  of  proceeding  produces  standards 
on  the  agreed  technical  areas  as  soon  as  possible  and  does  not  delay  such 
areas  while  other  more  contentious  issues  are  resolved.  If  Sbl-1  had 
waited  for  a full  solution  of  the  problem  of  tasking  calls,  rather  than 
include  the  known  requirements  of  START,  TRNON,  and  WAIT,  the  S61-1 
document  would  not  exist  as  a standard  today. 

I hope  this  letter  shows  you  that  the  intent  of  agreeing  on  the 
"technical  content"  of  Sbl-3  at  tin'  International  Meeting  of  the  1PW  in 
October  is  to  provide  a firm  base  to  write  the  standard,  and  that  all  the 
regular  review  procedures  required  for  standards  will  be  carried  out  as 
usual.  There  was  no  intent  to  avoid  such  reviews  and  there  was  no  belief 
on  my  part  that  any  of  the  existing  documents  on  Sbl-3  are  ready  for 
such  review. 


(\  — 


Yours  truly, 

I 


I 


0 V 


CC:  l)r.  T.  J.  Harrison  - 1.IJ.M. 
Dr.  T.  J.  Williams  - Purdue 


, M ' " 

Mitt hew  R.  Gordon-Clurk 

Chairman  1 1*W  FORTRAN  Committee  (TC  l) 

Chairman  ISA  SPbl  Committee 


REPORTS  OF  THE 

INDUSTRIAL  REAL-TIME  BASIC  COMMITTEE 


I 

| 

The  following  documents  are  included  here: 

1.  Report  of  the  Meeting  of  TC2-C  on  October  3-6,  1977. 

2.  Report  of  the  Activities  of  TC2-E  since  the  Fourth 
International  Workshop. 

3.  Real-Time  Basic,  Report  of  the  Activities  of  TC2-J  since 
the Last  Workshop . 

4.  Proposal  of  the  Real  Time  BASIC  Committee  (IRTB-E/77-17) . 

5.  Letter  from  Mr.  Koji  Yoda  re  IRTB-E/77-17  (Level  1 IRTB) . 
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Present : 


REPORT  OF  MEETING  OF  TC2  (BASIC) 
at  Purdue  3-6  Oct.  77 


G.  M.  Bull 
K.  Yada 
W.  Frakes 


(TC2  Europe) , Chairman 
(TC2  Japan) 

(TC2  USA) 


1.  The  document  (IRTB-E  14/77)  describing  the  cooperation 
between  ANSI  X3J2,  ECMA  TC21  and  Purdue  TC2  was  agreed. 


2.  Reports  of  activities  in  Japan  and  Europe  were  accepted. 

3.  Document  IRTB-E  17/77  (Level  1 Industrial  Real-Time 
BASIC)  was  discussed  fully  and  nearly  20  comments 
prepared  for  transmission  to  TC2  Europe.  The  comments 
addressed  errors,  responded  to  open  questions,  and 
suggested  changes. 

4.  Document  IRTB-E  20/77  (Level  1 Debugging)  was  discussed 
fully  and  comments  prepared  for  transmission  to  TC2 
Europe . 

5.  Document  IRTB-E  18/77  (Level  2 Industrial  Real-Time  BASIC) 
was  discussed  briefly  and  comments  prepared  for  trans- 
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Report  on  the  Activities  of  TC-2E  (Industrial  Real 
Time  BASIC)  of  the  International  Purdue  Workshop 
for  the  period  fall  1976  to  fall  1977 


1.  State  of  the  overall  organization 

During  the  period  to  be  reported  on  all  three  regional  committees 
have  been  active;  however,  at  this  time,  the  majority  of  the  work 
has  been  done  by  the  European  committee  whilst  the  American  and 
Japanest  committees  have  been  establishing  themselves. 

The  European  group  is  fortunate  since  it  has  achieved  full 
cooperation  between  about  20  members  based  in  research,  manu- 
facturing and  user  companies;  in  America  there  have  been  some 
problems  probably  due  to  commercial  confidentiality. 

The  European  group  has  had  four  meetings  and  has  also  organized 
a Process  Control  Computer  Workshop  in  Budapest. 

[j  During  the  course  of  working  on  the  standards  members  of  the 

committee  have  attended  meetings  of  several  other  standards 
Institutions  (ANSI,  ECMA,  BSI  and  DIN). 

; 

! 

2.  Achievements  of  the  Committee 

The  European  group  has  produced  approximately  twenty-five  working 
papers  which  habe  also  been  distributed  to  America  and  Japan  from 
whom  comments  have  been  received.  These  papers  reflect  the  three 
main  interests  of  the  group  namely:  Discussions  on  the  principal 
features  of  Real  Time  Programming,  evaluation  of  the  needs  of  users 
of  industrial  RTB  systems  and,  most  important,  the  work  on  a 
proposal  for  a standard  for  Real  Time  BASIC. 

At  this  time,  the  results  of  the  questionaire,  distributed  to 
various  IRTB  users,  are  available;  the  Standard  proposal  for 
IRTB,  which  will  also  be  distributed  to  both  ANSI  and  ECMA  will 
be  available  in  November,  1977. 


L * ^ preceding  page  nljlnk 
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An  official  co-operation  has  been  established  between  ANSI-  X3J2, 
ECMA-TC21  and  TC2  of  the  International  Purdue  Workshop.  In  this 
co-operation  TC2  is  responsible  for  defining  a proposal  of  the 
Real  Time  Enhancement  to  Standard  Minimal  BASIC.  The  committee 
is  also  able  to  influence  the  whole  BASIC  Standard  by  providing 
comments  and  suggestions  on  other  parts  of  the  language. 

A number  of  members  of  the  committee  have  reported  on  the  work 
of  the  group  and  on  personal  activities  in  the  field  of  BASIC 
to  various  workshops  and  conferences.  A number  of  implementations 
of  IRTB  produced  by  systems'  designers  and  main  frame  vendors 
are  being  influenced  by  the  work  of  TC2. 


3.  State  of  BASIC  Standardization 

During  1977  a Standard  for  Minimal  BASIC  has  been  introduced 
and  agreed  on  by  both  ANSI  and  ECMA.  Currently  the  work  on 
enhancement  modules  is  on-going.  A first  common  meeting  between 
ANSI,  ECMA  and  Purdue  will  take  place  in  London,  Nov.  14th  to 
18th,  1977.  At  this  meeting  TC2  will  present  a proposal  for  a 
Real  Time  Enhancement  module. 

The  proposal  consists  of  two  parts:  Level  1 being  the  proposal 
for  the  current  standardization;  Level  2 being  the  proposal  for 
future  enhancements.  Two  new  concepts  have  been  introduced  into 
BASIC:  concurrent  activities  with  scheduling,  synchronization 
and  communication  at  run-time;  and  input/output  (I/O)  to 
‘process  objects'.  Process  objects  are  typically  measurement 
and  control  points  in  a plant  interface,  such  as  temperature 
sensors  or  stenoing  motor  controllers.  The  functional  capabilities 
of  the  proposa  'rrespond  to  the  capabilities  of  I RT  FORTRAN  and 
LTPL,  while  the  sj.itax  aims  to  reflect  the  style  of  the  BASIC 
language. 
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4.  Personal  Affairs  and  Future  Plans 

The  International  Chairman  of  TC2  (currently  Eric  Crichton)  is  now 
a member  of  the  ANSI/ECMA  BASIC  Enhancement  Committee.  The  current 
regional  Chairmen  are  John  Herbster  (America),  Volkmar  Haase  (Europe), 
and  Koji  Yada  (Japan). 

As  Eric  unfortunately  cannot  accept  re-election  to  this  position, 
Gordon  Bull,  from  Hatfield  Polytechnic  England  (presently  at 
Dartmouth  College,  Hanover,  H.  N.)  has  been  nominated  to  be  the 
International  Chairman  elect.  Gordon  is  the  official  liason  person 
between  ECMA  and  ANSI  and  is  also  a member  of  TC2. 

The  final  standard  for  IRTB  (in  the  ANSI/ECMA  BASIC  Standard  frame- 
work) hopefully  will  be  completed  by  the  end  of  1978.  While  there 
are  likely  to  be  few  technical  problems  some  difficulties  may  have 
to  be  overcome  in  financing  the  attendence  of  TC2  members  at  meet- 
ings of  Standards  Committees  in  both  America  and  Europe. 


E . CricU 

v/.  Haase. 
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1 Activities  of  HT  - BASIC  Working  Group  in  Japan 

RT-  BASIC  Working  Group  in  Japan,  established  in  July,  1977,  is  now 
making  the  following  activities. 

( 1 ) Investigation  of  the  documents  on  RT  - BASIC 
( proceedings,  magazines,  papers,  etc.  ) 

( 2)  Analysis  and  evaluation  of  RT  - BASIC  for  CAMAC  specifications 

(3)  Evaluation  of  RT  - BASIC's  offered  by  manufacturers 

( Japan  Minicomputer,  Shimazu  Factory,  Shiba  Measuring  Instruments, 
ASR,  Textoronics,  etc.  ) 

( 4)  Investigation  into  minimal  BASIC 

( 5)  Discussion  on  the  documents  offered  from  foreign  RT  - BASIC  associations. 
( e.  g.  Dr.  Volkmar  H.  Haase,  Institut  fur  Angewandte  Informatik  ) 

( 6)  Preparation  of  the  comments  for  the  Joint  Meeting  which  is  going  to  be 
held  in  London,  November  12-14,  1977 

Summaries  of  the  activities  that  have  been  made  are  shown  in  RT  - BASIC 
WG  Minutes,  INSERT  I,  II,  III,  and  IV. 

Members  list  of  RT  - BASIC  Working  Group  in  Japan  is  shown  in 
INSERT  V. 

2 RT  - BASIC  in  Japan 

RT  - BASIC  is  not  so  popular  in  Japan  because  its  features  are 
considered  to  be  insufficient  for  industrial  applications.  The  application 
i iquiries  made  by  IPW  - J in  1974  showed  that  there  were  very  few  to  be 
utilized. 

However,  recent  inquiries  for  RT  - BASIC  for  CAMAC  as  shown  in 
INSERT  VI  reveals  that  RT  - BASIC  has  been  gradually  used  for  laboratory 
automation  and  in  the  field  of  computing  instrumentation  (INSERT  VII), 
which  proves  that  RT  - BASIC  has  been  noticed  in  Japan. 
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RT-  BASIC's  implied 
Real  Time  BASIC 
BICOMS 
BASIC  LAB 
BASIC  - 11/LAB 
MI  - BASIC 


by  Japanese  manufacturers  are  as  follows: 
Japan  Minicomputer,  Inc. 

Shimazu  Seisakusho,  Ltd. 

Takeda  Riken,  Inc. 

Automation  Systems  Research 
Shi basoku,  Inc. 


The  statements  of  above  RT  - BASIC's  are  quite  various. 

RT  - BASIC  WG  is  making  detailed  analysis  on  these  statements. 

3 RT  - BASIC  Standardization  in  Japan 

Activities  for  standardization  of  RT  - BASIC  have  been  just  started 
by  RT  - BASIC  Working  Group  in  Japan.  We  have  begun  with  analysis  and 
estimation  of  ANSI/ECMA  Standard  gained  in  September.  We  are  planning 
to  present  the  conclusion  to  Joint  Meeting  which  will  be  held  on  November 
12  to  14,  1977  in  London. 

Activities  on  RT  - BASIC  for  CAMAC  have  also  just  begua.  We  would 
like  to  endeavor  for  standardization  of  RT  - BASIC  in  cooperation  with 
foreign  countries. 

4 Discussion  on  ANSI/ECMA  Standard 

On  ANSI/ECMA  Standard,  there  is  still  a lot  of  ambiguities  left  for  us, 
since  RT- BASIC  WG  of  IPW-J  has  worked  on  this  standard  for  only  a few 
weeks. 

Attached  are  the  lists  of  questions  on  RT  BASIC  Enhancement  Level  I 


and  Level  2. 
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( L ) The  Cjucstionairc  on  HT- BASIC  level  1 

HT- BASIC  IPW-J 


1 ) What  manufacturer's  BASIC  did  become  the  sample  of  RT-  BASIC 
Enhancement  Level  1 ? 

2 ) What  kind  of  machine  is  supposed  in  Enhancement  Level  I ? 

Minicomputer  or  microcomputer  ? 

3 ) What  kinds  of  features  must  OS  have;  e.  g.  task  management  and 
file  management? 

4 ) Which  unit  level  docs  multiprocessing  have,  statement  unit  level  or 
subroutine  unit  level? 

5 ) What  does  'smallest  interruptable  element'  refer  to  in  practice? 

Is  it  unsuitable  to  interrupt  instantly  or  follow  the  interrupt  priority  level  ? 

6 ) What  is  the  feature  of  CHAIN  statement? 

7 ) Which  does  'X'  in  190-13  refer  to,  a byte,  a word  (16  bit),  or  a floating 

point  variable? 

•1 

8 ) Is  it  possible  to  write.multiple  assignment  statements  in  LET  statement? 

10  LET  A=C,  B=0,  C = 0,  LLO 

9 ) Is  it  allowed  to  write  multiple  assignment  statement  in  one  line? 

100  PRINT  "A-"  ; & INPUT  A 

10)  What  is  the  relation  between  parallel  sections  in  Enhancement  Level  1 
and  tasks  in  Level  2? 
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( 2 ) The  Questionaire  on  RT-HAS1C,  level  2 

RT- BASIC  IPW-J 


1 ) TASK  statement 

° How  many  digits  can  be  used  for  task  priority  set? 

° How  should  the  tasks  in  tin;  same  priority  be  handles? 

° IIow  should  the  difference  between  core  resident  task  and  overlay 
task  be  considered? 

° Are  all  the  task  schedulings  left  to  OS? 

2 ) WAIT  statement 

° Is  there  no  necessity  to  specify  absolute  hours,  minutes,  and 
seconds  for  TIME  specifiction ? 

Same  question  for  WHEN  TIME,  where  time-set  statement  is  required. 

3 ) Process  I/O 

Is  the  description  for  analog-digital  I/O  devices  established; 
such  as  standard  61.  i in  industrial  FORTRAN? 

4 ) Data 

° Will  the  internal  representation  of  DATA  gained  from  process  I/O 
be  handled  in  integers  or  floating  point  variables? 

4 handltngG  of  Data  liurn  digital— l/O-and  A/44  -converters 
-RCD,  lunary, -integers  of  1W-,  characters  (ASCII) 

5 ) File 

0 Do  data  file  structure  formats  also  tend  to  be  transformed  into  STD? 
-KEAi>/-M.Vffl EAP  WRITE /-MA-TWRITE 


L 
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1NSERT  I 

RT-HASIC  WG  Minutes  (The  1st  Meeting) 


1 Date  : July  28,  1977 

from  10:00  A.  M.  to  1:00  P.  M. 

2 Place  : JEIDA,  Council  Room 

3 Participants  : Yada  (ETL) 

Ogita  (1PCR) 

Onoda  (Japan  Minicomputer) 

Tanaka  (Toshiba) 

Furusawa  (JEIDA) 

Kogawa  (JEIDA) 

4 Materials  : No.  1-1  : The  Survey's  Report  on  Industrial  Computers  (51-A-100) 

No.  1-2  : ..  (52-A-117) 

No.  1-3  : RT- BASIC  for  CAMAC 

No.  1-4  : Minimal  BASIC 

No.  1-5  : CAMAC  Software,  IEEE,  1977 

No.  1-6  : CAMAC  Software,  A EC 

No.  1-7  : CASIC 

5 Proceedings  : Chairman,  K.  Yada 

1'  Plans  of  Investigation  into  RT- BASIC 

( 1 ) Investigations  into  documents  oh  RT- BASIC 

( 2 ) Evaluation  of  RT- BASIC  for  CAMAC 

( 3 ) Investigations  of  RT- BASIC  for  industrial  computers 


2 Acqusition  of  Documents 

The  documents  we  collected  could  be  classified  as  follows; 


° RT- BASIC 

( 1 ) (50-A-94)  Industrial  Computer  Systems 
( 2 ) (50-A-100)  » 

( 3 ) (52 -A -117)  » 

( 4 ) RT-BASIC  for  CAMAC 

( 5 ) Purdue  Europe  RT-BASIC.  First  Report,  1975 
( 6 ) HP -RT-BASIC 
( 7 ) Minimal  BASIC 
( 8 ) TEK  4051  BASIC 
( 9 ) IBM  5100  BASIC 

° CAMAC 

( 1 ) CAMAC  Software,  IEEE,  1977 
( 2 ) CAMAC  Software,  A EC 
( 3 ) CASIC 


■PH  | 
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3 Treatment  of  RT- BASIC  for  CAMAC 

Translations  of  RT- BASIC  for  CAMAC  will  be  treated  as  recommended 
standards  by  RT-WG. 

4 Relationship  with  Purdue  Workshop 

RT-WG  Will  present  some  announcement  for  next  Purdue  Workshop 
which  will  be  held  from  October  3 to  6,  1977.  Relationships  with  ESONE, 
IEC,  etc.  are  also  desirable. 


5  Additional  members 

WG  asked  thses  persons'  participation 
° Mr.  Iharada  (Mitsubishi) 

° Mr..  Kumagai  (Pana  Facom) 

° Mr.  Miura  (High  Energy  Lab.) 


6  Next  Meeting 


Date  : August  25,  1977 
from  10:00  A.  M. 


Agenda 


: 1 Investigation  of  answers  for  inquiries 

2 RT-BASIC  Status  Quo  of  Toshiba  and  Japan  Minicomputers 

3 RT-BASIC  for  CAMAC 

4 The  other  items 
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1NSKKT  II 


HT- BASIC  VVC,  Minute;;  (Tho^2nd  Meeting) 


1 Date 

2 Place 

3 Participants 


4 Materials 


August  25,  1977 

from  10:30  A.M.  to  1:00  P.M. 

JE1DA,  Council  Room 

K.  Yada  (ETL) 

Ogita  (IPCH) 

Tanaka  (Toshiba) 

Ohba  (Shimazu) 

Hirose  (Mitsubishi) 

Kawakami  (Fujitsu) 

Onoda  (Japan  Minicomputer) 

YoshiUa  (Fujitsu) 

Kumagai  (Pana  Fa  com) 

Furusawa  (JEIl)A) 

Kogawa  (JEIDA) 

No.  2-1  : Material  for  the  2nd  Meeting 

No.  2-2  : Reports  of  the  Industrial  HT-HASIC  COMM. 

No. 2-3  : RT-BASIC's  of  Japan  Minicomputers  and  NOVA 
No.  2-4  : Inquiries  for  Ceneral  Status  of  BASIC’  Languages 
Utilization  (Proposal) 

No.  2-5  : TEKTRONIX  4051  BASIC 

No.  2-6  : Comments  on  R-T  BASIC  for  CAMAC 


5 Proceedings 


Chairman,  K.  Yada 


1 Confirmation  of  the  last  minutes 

2 Self-introductions  by  new  members 

Ohba,  Hirose,  Kawakami,  Yoshida,  and  Kumagai 

3 Contact  witl^foreign  countries 

Foreign  related  committees  were  announced  us  follows; 

Dr.  T.J.  Williams  (Purdue  Univ. ) 

Mr.  E.R.  Crichton  (Kent  Automation  Systems) 

Mr.  J.  Herbster  (Herbster  Scientific) 

Dr.  II.  Haase  (Institut  Fuer  Angewandte  Informatik) 
l)r.  H.  Meyer  (ESONE  Secretariat) 

Mr.  L.  Cost rel lo  (NBS) 

Mr.  C.J.  Stanford  (I EC) 


I 
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Moroover,  there  announced  was  a suggestion  that  WG  will  present 
some  materials  for  the  BASIC  Committee  at  International  Purdue 
Workshop  which  will  be  held  on  October  3 to  6,  1977  in  U.S.  A. 


4 Introduction  of  NOVA  RT~  BASIC  (Japan  Minicomputers) 

Mr.  Onoda  of  Japan  Minicomputers,  Inc.  described  about  NOVA  by 
referring  to  material  No.  2-3,  especially  on  bit  process  functions, 
process  I/O  features,  plotter  process  features,  and  multi-tasks 
process  features. 

5 Comments  of  RT- BASIC  for  CAMAC 

Mr.  Tanaka  of  Toshiba  Electric,  Inc.  presented  some  comments  on 
the  following  items  in  DRAFT  PROPOSAL  RT- BASIC  FOR  CAMAC 
(June,  1979)  by  referring  to  material  No.  2-6. 

° Concepts  of  TASKING 
° Process  variables 
° Control  statements 
“Interrupt  processing 
° ERROR  statements 

G Inquiries  for  the  general  status  of  BASIC  languages  utilization 

Mr.  Onoda  of  Japan  Minicomputers,  Inc.  announced  about  the 
proposal  for  inquiries  by  referring  to  material  No.  2-4,  which  was 
agreed  to  be  realized  before  the  next  Meeting  through  several 
examinations. 

7 Next  Meeting 

Date  : September  16,  1977 
from  10:30  A.  M. 


1 


I 

) 

' 


I 
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1 NS  HUT  III 


HT- BASIC  WC1  Minutes  (The  3rd  Meeting) 


1 Date  : September  16,  1977 

from  10:30  A.  M.  to  1:30  P.  M. 

2 Place  : JEIDA,  Council  Hoorn 

3 Participants  : Yada  (ETL) 

Ogita  (IPCR) 

Onoda  (Japan  Minicomputer) 
Yoshida  (Fujitsu) 

Kumagai  (Pana  Facom) 
Inomato  (Atomic  Energy) 
Shirako  (Fujitsu) 

Ilirose  (Mitsubishi) 

Ihara  (Mitsubishi) 

Tanaka  (Toshiba) 

Ohba  (Shimazu) 

Yanai  (Shibasoku) 

Okada  (ASH) 

Furusavva  (JEIDA) 


4 Materials  : No.  3-1 
No,  3-2 
No.  3-3 

No.  3-4-1 
No.  3-4-2 
No.  3-5 
No.  3-6 
No.  3-7 
No.  3-8 
No.  3-9 

No.  3-10 


MI-BASIC,  Software  Manual 
Industrial  BASIC 

Report  on  HT  Extension  and  Implementations 
of  RT-BASIC 

Purdue  Europe  TC-2,  Industrial  HT- BASIC 
HT- BASIC,  Section  190,  Level  1 Enhancement 
HT- BASIC  for  CAMAC  (ESONl/RTB/02) 

The  Development  of  CAMAC  Software 
Real-Time  BASIC  for  CAMAC 
ESON E/PTB / 02  (Announcement) 

Inquiries  for  General  Status  of  BASIC  Language 
Utilization  (Proposal) 

HT- BASIC  for  CAMAC  from  the  view  point  of 
Minimal  BASIC 


5 Proceedings : Chairman,  K.  Yada 

1 Confirmation  of  thellast  minutes 

n 

2 Introduction  of  Shibasoku  HT- BASIC 

MI- BASIC,  developped  in  technical  cooperation  with  Marconi 
Instrument,  Ltd.  in  England  was  introduced  by  Mr.  Yanai 
(Shibasoku).  This  BASIC,  first  used with  PDP-11,  is  now  imple- 
mented with  LSI-11  to  sell.  Explanation  was  made  on  program  data 


IL 
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format,  statement  forms,  and  program  operation  modes. 

3 Geaerai  status  of  industrial  BASIC  in  Japan 

The  result  of  the  investigation  on  Industrial  1{T-  HASH'  made  by 
referring  to  material  No.  3-2.  Surveys  wore  made  into  documents 
and  to  produce  a comparative  table  on  BASIC. 

4 On  feature  extention  of  KT- HASIC  for  CAMAC 

Mr.  Yoshida  (Fujitsu)  explained  in  comparison  with  Minival  HASIC 
by  referring  to  material  No.  3-10. 

5 Proposal  for  the  inquiry  were  explained  by  Mr.  Tanaka  (Toshiba) 
and  approved.  Mail  list  will  be  prepared  at  Executive  Office 
objecting  measuring  instrument  users. 

6 The  other  items 

( 1 ) Material  No.  3-4-1  will  be  investigated  by  Mr.  Yoshida  (Fujitsu) 

( 2)  No.  3-4-2  will  be  surveyed  by  Mr.  Ohba  (Shimauu)  and  No.  3-4-3, 
by  Mr.  Onoda  (Japan  Minicomputer),  in  comparison  with 
BASIC'S  of  their  companies. 

( 3)  No.  3-5  through  No.  3-8  will  be  investigated  at  Nuclear  Lab. 

7 Next  Meeting 

Date  : September  27,  1977 


1 . z 
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INSKHT  IV 


RT-  BASIC  WG  Mi  null's  (The  4th  Mooting) 

1 Date  : September  27.  1077 

from  2:00  P.  M.  to  4:30  P.  M. 

2 Place  : JE1DA,  Council  Room 

3 Participants  : Yada  (ETL) 

Ogita  (1PCR) 

Onoda  (Japan  Minicomputer) 

Shirako  (Fujitsu) 

Yoshida  (Fujitsu) 

Kumagai  (Pana  Fa  com) 

Hori  ( Toshiba) 

Ohba  (Shimazu) 

Yamai  (Shibasoku) 

Okuda  (A . S.  K. ) 

Furukawa  (JEIDA) 

4 Materials  : No.  4-1  ; Enhancement  to  Minimal  BASIC 

(Fujitsu) 

No.  4-2  : Industrial  Real-Time  BASIC,  section  190- Level 
Enhancement 

5 Proceedings  : Chairman,  K.  Yada 

1 Industrial  real-time  BASIC 

The  general  concept  of  industrial  real-time  BASIC  was  explained 
by  Mr.  Yoshida  (Fujitsu).  On  its  level-1, was  commented  by  Mr. 

Yanai  (Shibasoku),  and  level-2  by  Ml*. Onoda  (Japan  Minicomputer), 
There  were  detailed  questions  and  requirements  asked  by  the  members 
on  above  subjects. 

2 Joint  Meeting  on  BASIC  in  London 

It  was  agreed  that  each  member  should  prepare  any  questions  and 
inquiries  to  present  for  the  Joint  Meeting  in  London  before  the 
next  Meeting. 

6 Next  Meeting 


1 


Date  : October  25,  1977 
from  10:00  A . M. 
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Real  - Time  BASIC  WG  Members  List  ( 1PW  - J ) 
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Manager 
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Tokyo,' 

0424-61-2141 

Naofumi  Ogita 
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Inqurics  for  General  status  ol’  BASIC  Languages  Utilization  (Proposal) 

RT  - BASIC  WG,  IPW  - J 
1977  8/25  OS 

( 1 ) General  BASIC 

1 .1  Do  you  use  a BASIC  language  now? 

a.  yes  b.  no  c.  no,  but  planning  to  use 

1.2  What  do  you  or  will  you  use  BASIC  for? 

a.  business  transaction 

b.  scientific  and  technical  computing 

c.  process  control 

d.  instrumentation 

I.  3 What  type  of  computer  do  you  use  BASIC  with? 

a.  TSS 

b.  minicomputer 

c.  microcomputer 

name  of  the  product  ( ) 

( 2 ) Real-time  BASIC 

2-.V  Do  you  use  real-time  BASIC  now? 

a.  yes  b.  no  c.  no,  but  planning  to  use 

2.2  Where  was  your  real-time  BASIC  developped? 

a.  home  brewed 

b.  by  other  manufacturer 

c.  by  foreign  manufacturer 

name  of  your  BASIC  language  ( ) 

manufacturer  ( ) 

OS  ( i) 


2.  3 Are  you  .satisfied  with  the  capacity  of  your  real-time  BASIC V 

a.  yes  b.  no 
Why  are  you  satisfied  or  dissatisfied? 


( 3 ) Interface  with  Measuring  Instruments 

What  is  your  interface  standard  and  its  supporting  language? 
Where  were  they'  developped? 

Please  check  in  the  appropriate  blanks. 


* Please  check  the  software  manufacturer  of  your  interface 

* Please  cheek  your  interface  hardware  manufacturer. 
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I NOUS  TRIAL  REAL-TIME  BASIC 


Section  190  - Level  1 Enhancement 


INTRODUCTION 

For  use  in  real-time  applications  two  new  concepts  must  be 
introduced  into  BASIC:  concurrent  activities  with  scheduling, 
synchronisation  and  communication  at  run-time;  and  input/output  (1/0) 
to  'process  objects'.  Process  objects  are  typically  measurement  and 
control  points  in  a plant  interface,  such  as  temperature  sensors  or 
stepping  motor  controllers. 

Concurrent  activities  are  introduced  in  level  1 by  START 
statements  activating  'parallel  sections'  within  a program.  WAIT 
statements  are  defined  to  suspend  a parallel  section,  and  allow  it  to 
continue  at  an  absolute  time,  after  a timed  delay,  or  in  response  to 
an  'event'  (a  software  signal  or  a hardware  interrupt).  Communication 
between  concurrent  activities  is  via  normal  variables,  since  all 
variables  are  global  to  the  whole  program. 

Process  1/0  is  by  means  of  read  and  write  statements  that 
transfer  data  between  process  objects  and  the  computer  memory.  The 
names  and  other  attributes  of  the  communication  paths  used  by  the 
system  to  perform  the  I/O  are  given  in  declaration  statements.  If  a 
filing  system  is  implemented  the  declarations  can  be  put  into  one  or 
more  'environment  description'  files  that  are  accessed  by  USE 
statements  at  the  head  of  the  program,  otherwise  the  declarations 
themselves  must  be  at  the  head  of  the  program.  Jn  this  way  a program 
can  be  divided  into  two  parts:  an  implementation  dependent 
environment  description,  and  implementation  independent  programs  that 
share  the  environment  description,  and  for  which  the  particular 
process  peripheral  interface  system  is  completely  transparent. 
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-47-  In  the  level  2 enhancement  (section  ?09)  the  concept  of  a task  is 
-48-  introduced.  A task,  tike  a sub-program,  is  an  independently  compiled 
-49-  program  with  its  own  local  variables,  but  it  is  activated  in  the  same 
-50-  way  as  a parallel  section  rather  than  called  with  a parameter  list. 
-51-  Inter-task  common i c at  ion  is  by  read  and  write  statements  that 
-52-  transfer  messages  over  communication  paths.  Message  communicat ion 
-5?-  paths  are  declared  in  the  same  way  as  process  object  communication 
-54-  paths. 

-55- 
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190  PROGRAM  STRUCTURE 


190.1  General  description 

A program  comprises  a header  and  one  or  more  parallel  sections. 

The  header  determines  the  process  environment  for  the  program,  by 
declarations  or  by  USE  statements  that  refer  to  environment 
description  files  containing  the  declarations,  according  to  the 
facilities  available  in  the  implementation. 

Each  parallel  section  is  named,  and  is  delimited  by  the  keywords 
PARACT  and  PAREND.  Scheduling  statements  refer  to  parallel  sections 
by  name  rather  than  by  line  number,  in  order  to  be  compatible  with 
the  level  2 multi-tasking  extension. 

Within  a parallel  section  program  lines  are  executed  in 
sequential  order  as  defined  for  Minimal  BASIC.  Control  cannot  be 
transferred  between  parallel  sections  with  the  program  control 
statements  GOTO,  G0SUB  or  ON:  a parallel  section  is  started  at  its 
lowest  line  number  by  a scheduling  statement.  Execution  of  a PAREND 
or  PAREXIT  statement  terminates  execution  of  the  corresponding 
parallel  section.  Execution  of  a STOP  statement  terminates  the  whole 
prog  ram . 

Section  191  contains  the  definition  of  the  dec-statement  and 
section  192  contains  the  definition  of  i-o-statement . 


190.2  Syntax 

1.  program  > header?  par-section*  end-line 

2.  statement  > i-o-statement/schedul ing-statement 

/parexit-statement 

3.  header  = (use- l ine/dec-l ine) * 


4.  use-line 


line-number  use-statement  end-of-line 


f 


-J  I'j- 


-4?- 

5. 

use-statement 

= 

USE  quoted-string 

-43- 

-44- 

6. 

dec-line 

= 

line-number  dec-statement  end-of-line 

-45- 

-46- 

-47- 

7. 

par-sect  ion 

= 

paract-line  block*  parend-line 

-48- 

-49- 

8. 

paract-l ine 

line-number  PARACT  section-name  end-of-line 

-50- 

9. 

sect  ion-name 

= 

letter  digit? 

-51- 

-5?- 

10. 

parend-l ine 

= 

line-number  PAREND  end-of-line 

-53- 

-54- 

11. 

parex i t-statement 

= 

PAREXIT 

-55- 

- 1 - 

190.3 

Fxampl cs 

- 2- 

- 3- 

4. 

?0  USE  "DKl :PR0DEC" 

- 4- 

- 5- 

7. 

1000  PARACT  03 

- 6- 

1010  WAIT  TIME  = 

17*60*60 

- 7- 

1070  PRINT  "TIME 

TO 

60  HOME" 

- 8- 

1030  PAREND 

- 9- 

-10- 

190.4 

Semant i c s 

-11- 

-1?- 

The  quoted  string 

in 

a USE  statement  identifies  an  'environment 

description  file',  ie, 


containing  declarations 


communication  paths  to  process  objects  and  from  interrupts.  Its 
format  is  implementation  dependent. 

Program  execution  starts  at  the  lowest  line  number,  ie.'  at  the 
beginning  of  the  first  parallel  section.  Other  parallel  sections  are 
started  explicitly  by  START  statements. 

If  a CHAIN  statement  is  executed,  then  all  outstanding  scheduling 
calls  to  start  or  continue  parallel  sections  must  be  cancelled,  since 
after  execution  of  the  CHAIN  statement  the  programs  to  service  them 
will  no  longer  be  in  memory. 

A PARACT  statement  is  not  executable,  its  purpose  is  to  introduce 
the  name  of  a parallel  section  and  indicate  its  lexical  beginning.  A 
PAREND  statement  indicates  the  lexical  end  of  a parallel  section. 
Execution  of  a PAREND  or  PAREXIT  statement  terminates  the  section. 
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190.5  Exceptions 

The  file  referenced  in  a USE  statement  cannot  be  accessed. 

A GOTO,  GOSUB,  IF  or  ON  statement  refers  to  a tine  in  another 
parallel  section. 

190.6  Remarks 

Some  implementations  may  have  an  additional  parameter  in  the 
PARACT  statement  indicating  a priority  level  o<  execution  of  the 
section.  For  these  implementations,  rule  8 becomes: 

8.  paract-line  = line-number  PARACT  section-name  colon 

integer  end-ot-line 

where  the  integer  indicates  t tie  priority  level,  higher  numbers 
representing  higher  priority. 

The  definition  of  parallel  sections  implies  multi-thread,  not 
single-thread  execution.  Multi-thread  means  that  from  a state  where 
several  parallel  sections  have  been  started,  the  return  of  control 
does  not  necessarily  follow  the  same  path  in  reverse,  as  in  the  rase 
of  nested  subroutine  calls  for  example.  A consequence  of  single 
thread  is  that  a WAIT  statement  would  suspend  the  whole  program, 
whereas  the  intention  is  to  allow  other  activities  to  proceed  during 
the  wait ing  per iod . 
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" The  data  in  all  DA  1 A statements  throughout  the  program  is 

- 2-  concatenated  as  defined  in  Minimal  BASIC.  Fach  parallel  section 

must,  however,  maintain  its  own  conceptual  pointer,  since  a single 

- 4-  pointer  would  result  in  unpredictable  behaviour  due  ihe'IC.  the 

- 5-  indeterminate  sequence  of  execution  of  the  sections.  A RislOKt 

- 6-  statement  in  a parallel  section  sets  the  local  conceptual  pointer  to 

- 7-  the  beginning  of  the  data  in  the  whole  program. 

- 8- 
- 9- 

-10-  190.7  Inter-module  dependence 

-11- 

The  USE  statement  implies  the  existence  of  a filing  system.  If  a 
-13-  filing  system  exists  it  could  be  outside  the  BASIC  language,  so  that 

-14-  the  environment  description  files  must  be  created  independently,  or 

-15-  it  could  bo  the  Files  Enhancement  in  which  case  the  environment 

-16-  description  could  be  handled  by  the  BASIC  system. 

-17- 

”1?"  for  interrupt  driven  systems,  any  sub-progi ams  called  from 

-19-  parallel  sections  must  be  either  non- int er rupt abl e or  re-entrant. 

-70- 
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190.8  Resolved  questions 
None . 

190.9  Open  questions 

What  is  the  smallest  interruptable  element?  A simple 
implementation  may  delay  interrupt  servicing  until  the  end  of  the 
current  statement,  but  this  could  cause  very  long  delays, 
particularly  in  the  case^of  INPUT  and  PRINT  statements.  On  the  other 
hand,  for  implementations  that  store  a value  in  more  than  one 
computer  word,  access  to  a variable  used  for  communication  between 
sections  must  not  be  interrupted  or  the  result  could  be  nonsense.  Is 
it  possible  to  make  a recommendation,  or  should  the  decision  be  left 
entirely  to  the  implementer?  Should  the  user  be  provided  with  a 
mechanism  for  protecting  a statement,  a block  of  statements  or  a 
parallel  section  against  being  interrupted? 

How  should  DATA,  RFAD  and  RFSTORC  statements  be  handled? 

1.  As  in  Minimal  BASIC  with  a single  conceptual  pointer  incrementing 
through  all  the  data  in  sequence. 

?.  With  DATA,  RFAD  and  RFST0RE  local  to  each  parallel  section. 

3.  With  a local  pointer  in  each  section,  but  a single  set  of  data 
derived  from  all  the  DATA  statements  in  the  program. 

Solution  1 is  not  viable  if  RFAD  or  RESTORE  statements  appear  in  more 
then  one  parallel  section  because  the  sequence  of  execution  of  the 
sections  can  be  unpredictable.  ^Solution  2 does  not  allow  the  same 
data  to  be  used  in  different  sections  unless  the  data  itsell  is 
duplicated,  and  it  changes  the  semanl ic  definition  of  DATA  statements 
in  Minimal  BASIC.  Solution  3 has  been  tentatively  chosen  in  section 
190.6  since  it  is  the  simplest  viable  solution  and  it  requires  t he 
minimum  changes  to  definitions  in  other  modules.  This  solution  could 
lead  to  confusion  in  that  changing  the  DATA  statements  in  one 
parallel  section  changes  the  sequence  of  data  read  in  all  other 
sec  t ions . 
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* I'  191  DECLARATIONS  AND  THE  INVIR0NMINI  DESCRIPTION 
- 2- 

- i. 

- 4-  191.1  General  description 

- 5- 

■ 6-  Declaration  statements  define  the  attributes  of  communication 

- 7-  paths  between  elements  of  a real-time  system.  The  communication 

- 6-  paths  link  to  process  objects  and  to  interrupt  sources. 

- o- 
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A declaration  gives  the  name  of  a path  and  its  attributes.  The 
attributes  are  essentially  system  dependent,  and  will  typically 
include  the  address  of  the  element  and  the  format  of  its  data.  The 
format  information  allows  the  system  to  perform  automatic  data 
t r ans f ormat i on,  such  as  between  HCP  in  a process  object  and  floating 
point  in  the  internal  representation.  An  impl ement at  ion  may  allow 
procedure  names  in  a declaration  so  that  special  devices  can  be 
handled  by  the  standard  mechanism.  The  procedures  could  for  example 
handle  access  via  a multiplexer  with  a long  switching  time,  or 
special  Gray  code  devices.  The  procedures  are  invoked  automat ical l y 
each  time  the  communication  path  is  accessed. 


191.2  Syntax 

1.  dec-statement 

2.  process-path-dec 

3.  process-dimension-dec 

4.  path-name 

5.  process-attribute-dec 

6.  ident 

7.  qualifier 

8.  interrupt-path-dec 


= process- pa t h- de c / interrupt  - pa th-dec 

= process-dimension-dec 
/process-attr ibute-dec 

= PROPIM  path-name  open  integer 
(comma  integer)?  close 

= letter  digit? 

= PRO  qualifier?  ident  quoted-string 

= path-name  (open  integer  (comma 
integer)?  close)? 

= IP/OP/IO  colon 

= INTERRUPT  path-name  colon  path-name 
quo  ted- st  r ing 


191.3  Examples 

3.  ^30)  PRODIM  T1 (10,3) 
5.  /35\  PRO  C "27" 


'.  ^50) 


PRO  (IP)  T 1 (2,3)  "(5,1)  (BCD  4)" 
INTERRUPT  01:  C "9" 
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191.4  Semant  i c s 

1- 

?-  A process  path  can  communicate  with  a sinqle  entity  or  an  array 

3-  of  entities  in  the  interface  system.  The  elements  of  such  an  array 

4-  are  not  necessarily  associated  at  the  hardware  level  - as  for  an 

5-  array  of  variables,  an  array  of  process  objects  is  used  when  they  are 

6-  treated  as  a logical  group  in  the  program  (for  example  temperature, 

7-  level  and  flow  rate  in  each  of  5 reactor  vessels  could  be  handled  as 

8-  a 3 by  5 array).  The  declarations  for  such  an  array  must  first 

9-  declare  the  dimensions  of  the  array  in  a process  dimension  statement, 

10-  and  then  declare  the  attributes  of  each  entity  in  a process  attribute 

11-  declaration. 

IP- 

13-  The  qualifier  can  be  -used  to  indicate  an  input-only  or 

14-  output-only  process  object.  The  translator  uses  this  information  to 

15-  check  the  validity  of  I/O  statements.  The  default  qualifier  is  10. 

16- 

17-  The  second  path-name  in  an  interrupt  declaration  is  the  name  of 

18-  the  path  communicating  with  the  process  object  that  is  the  source  of 

19-  the  interrupt.  This  information  may  be  needed  by  the  system  to 

PO-r  enable  and  disable  the  interrupt.  The  quoted  string  identifies  the 

PI-  interrupt  route  into  the  computer;  it  could  be  for  example  an 

22-  interrupt  vector  number. 

23- 

P4-  In  the  case  of  an  array,  the  process  dimension  declaration  must 

P5-  precede  the  associated  process  attribute  declarations,  and  all 

?6-  members  of  the  array  must  be  defined  in  process  attribute 

27-  declarations. 

?8- 

29-  191.5  Exceptions 

30- 

31-  A member  of  an  array  is  not  defined  by  a process  attribute 

32-  declaration. 

33- 

34-  Other  errors  are  system  dependent,  and  are  mainly  concerned  with 

35-  the  parameters  of  the  particular  process  peripheral  system  (for 

36-  example  illegal  device  addresses). 

37- 

38-  191.6  Remarks 

39- 

40-  It  is  intended  that  the  set  of  declarations  for  process  and 

41-  interrupt  communication  paths  be  written  by  the  person  who  configures 

4?-  the  system,  and  stored  in  one  or  more  'environment  description 

43-  files'.  The  application  programmer  will  have  available  a list  of  the 

44-  names  used  and  the  functional  characteristics,  and  will  refer  to  the 

45-  declarations  by  a USE  statement  in  his  program.  There  can  thus  be  a 

46-  division  of  responsibilities  between  these  two  types  of  expertise. 

47- 
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An  implementation  may  include  system-defined  names  for  paths 
connecting  to  permanently  installed  process  objects.  Such  names  do 
not  need  dec l arat ions , either  in  the  program  or  in  an  environment 
description  file. 


191.7  Intermodule  dependence 

There  are  problems  in  passing  communicat ion  paths  as  arguments  to 
sub-programs.  The  sub-program  must  include  a formal  declaration  for 
the  entity,  and  the  actual  argument  must  be  passed  in  a way  that  is 
independent  of  the  number  of  parameters  needed  to  define  it. 
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The  files  enhanc rment  committee  is  asked  to  comment  on  the 
remarks  concerning  I/O  in  section  191.9. 


191.8  Resolved  questions 
None 

191.9  Open  questions 

Should  arrays  of  process-object  communication  paths  be  in  the 
level  1 or  the  level  2 enhancement? 

Should  process  objects  have  an  identifying  character,  by  analogy 
with  the  S indicating  a string  quantity?  The  problem  is  that  IR1P  may 
need  process  objects,  interrupts,  software  events,  integers,  bit 
patterns,  section  names  and,  for  level  2,  program  names  and  message 
path  names.  Firstly,  there  are  not  enough  special  characters 
available,  and  secondly,  even  if  there  were,  it  is  arguable  that  such 
a proliferation  of  special  characters  would  be  contusing  rather  than 
helpful.  A better  solution  is  to  implement  mult i-character  names  so 
that  the  user  can  solve  the  problem  by  choosing  meaingful  mnemonics. 

Two  kinds  of  1/0  are  required  in  RT-PASIC:  process  1/0  and  the 
I/O  defined  in  Nucleus  and  the  Files  Enhancements.  There  are  three 
poss ib i l i t ies : 

1.  Handle  process  1/0  with  INPUT  and  PRINT  as  in  the  Files 
enhancement . 

?.  Handle  file  1/0  in  the  same  way  as  process  1/0  by  adding  a 
per ipheral-path  declaration. 

3.  Define  two  types  of  I/O. 


J 
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-38- 

-39- 

-40- 

-41- 

-42- 

-43- 

-44- 

-45- 

-46- 

-47- 

-48- 

-49- 

-50- 

-51- 

-52- 

-53- 

-54- 

-55- 

-56- 

-57- 

-58- 

-59- 
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The  IRTB  committee  does  not  favour  solution  1 because  the 
formulation  ' channel-number*  is  not  very  convenient  for  handling  the 
typical  case  of  hundreds  of  process  objects,  usually  grouped  in 
arrays.  The  use  of  names  rather  than  numbers  is  essential  for 
program  intelligibility.  Also  PRINT  does  not  have  the  right 
connotation  for  the  output  of  a set  point  to  a temperature  controller 
for  example. 

Solution  2 is  elegant.  A peripheral-path  declaration  could  be  of 
the  form: 

per ipheral-path-dec  = CHANNEL  qualifier?  path-name,  quoted-string 

i 

eg. 

r V 

CHANNEL  (10)  F3-."0K0:  RUN1.DAT” 

Process  I/O  and  control  statements  could  then  be  used,  eg: 

CON  F 3 : OPEN 

WRITE  F3:  A,R, C 

Solution  3 is  probably  the  only  acceptable  one.  However,  an 
implementation  may  adopt  solution  2 as  a local  option. 
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- 1-  192  PROCESS  I/O 

- 2- 

- t. 

- 4-  192.1  General  description 

- 5- 

“ 6-  REAP  and  WRITE  statements  are  used  to  move  data  over 

- 7-  communication  paths  between  elements  of  the  system. 

- 8- 

“ 9-  The  computer  memory  reference  for  a READ  statement  is  a single 

-10-  variable,  and  for  a WRITE  statement  it  is  an  expression. 

-11- 

-12- 

-13-  192.2  Syntax 

-14- 

”15-  1.  i-o-statement  = read-statement/write-statement 

-16- 

“17-  2.  read-statement  = READ  path-name  colon  read-item 

-18- 

-19-  3.  read-item  = variable 

-20- 

-21-  4.  write-statement  = WRITE  path-name  colon  write-item 

-22- 

-23-  5.  write-item  = read-item/expression 

-24- 
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I 

ij 

» 

[| 


-25- 

-26-  192.3  Examples 

-27- 

-28-  2. 

-29- 

-30-  4. 

-31- 
-32- 

-33-  192.4  Semantics 

-34- 

-35-  Since  there  is  no  hidden  parallelism  in  BASIC,  READ  and  WRITE 

-36-  statements  imply  ’wait  for  completion'  so  it  can  be  assumed  that  the 

-37-  data  has  been  transferred  when  the  next  statement  in  sequence  is 

-38-  executed. 

-39- 

-40-  ' . 

-41-  192.5  Exceptions 

-42- 

-43-  A write  operation  directed  to  an  input-only  device. 

-44- 

-45-  A read  operation  directed  to  an  output-only  device. 

-46- 

-4 7-  A mis-match  of  data  types  between  a variable  or  expression  and  a 

-48-  process  object. 

-49- 

-50- 

-51-  192.6  Remarks 

-52- 

-53-  Some  process  peripheral  systems  require  control  operations,  for 

-54-  example  to  initialise  a device,  or  to  enable  and  disable  an  interrupt 

-55-  or  data  taking.  Such  control  operations  change  the  status  of  process 

-56-  objects  without  transferring  data  that  is  significant  to  the 

-57-  programmer  (the  change  of  status  may  be  effected  by  writing  to  a 

-58-  status  register,  but  such  mechanisms  should  be  transparent  at  the 

-59-  level  of  a BASIC  program. 

-60- 


400  READ  C:  VI 


,440/WRITE  Cl:  3.2*Y/(X+Z) 
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- 1"  However,  some  process  peripheral  systems  have  no  control 

- 2-  operations  but  are  only  able  to  transfer  process  data.  Such  systems 

- 3-  clearly  cannot  execute  control  operations,  and  since  the  definition 

- 4-  of  a conforming  implcmentat ion  is  that  it  shall  interpret  every 

- 5-  statement  in  the  language  according  to  the  defined  semantics,  these 

- 6-  systems  would  be  precluded  from  claiming  conformation  if  control 

- 7-  statements  were  included  in  the  definitive  standard. 

• - 8- 

- 9-  In  the  interests  of  standardisation  between  implementations  that 

-10-  have  control  operations,  the  following  supplementary  rules  are  given. 

-11-  If  an  element  of  a system  is  able  to  execute  an  operation  that  is 

-12-  described  by  one  of  the  control  keywords,  then  that  action  should  be 


A 


” 11  1 
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invoked  by  the  appropriate  control  statement.  If  a system  includes 
other  control  actions,  such  actions  should  be  expressed  by  control 
statements  using  an  appropriate  implementation-defined  keyword. 


1.  control-line 


= line-number  control-statement  end-of-line 


2.  control-statement  = CON  path-name  colon  control-act  ion 


3.  control-action 


OPEN/ CLOSE /ENABLE /DISABLE /I  NIT 
/[implementation  defined! 


192.7  Inter  Module  dependence 


None . 


-31-  192.8  Resolved  questions 


192.9  Open  questions 

The  words  READ  and  WRITE  have  been  chosen  because  they  are 
commonly  used  to  refer  to  I/O.  Syntactically  and  semantically  this 
use  of  READ  is  different  from  the  normal  READ  in  BASIC,  so  should 
other  keywords  be  found,  perhaps  SEND  and  RECEIVE? 


193  SCHEDULING  STATEMENTS 
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193.1  General  description 

In  level  1 all  scheduling  of  parallel  sections  is  by  means  of 
START  and  WAIT  statements.  A START  statement  unconditionally  starts 
the  named  parallel  section;  if  it  is  required  to  execute  the  section 
conditionally,  for  example  in  response  to  a particular  interrupt, 
then  the  section  should  have  the  appropriate  WAIT  statement  at  the 
beginning.  A WAIT  statement  can  suspend  a section  for  a time 
interval,  until  a specified  absolute  time,  or  until  a specified  event 
occurs. 


Level  2 provides  conditional  START  and  SIGNAL  statements. 
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18- 

19- 

193.2 

Syntax 

20- 

21- 

22- 

1. 

schedul ing-st atement 

start-statement/ wait-statement 
/signal-statement 

23- 

24- 

2. 

start-statement 

= 

START  section-name 

25- 

26- 
27- 

3. 

wait-statement 

WAIT  ( interval-cond i t ion/ t ime-cond i t ion 
/event-condi t ion) 

28- 

29- 

4. 

interval-condi t ion 

= 

DELAY  equals  numeric-expression 

30- 

31- 

5. 

t ime-cond i t ion 

= 

TIME  equals  numeric-expression 

32- 

77. 

6. 

event-condi t ion 

S 

EVENT  event-name 

34- 

35- 

7. 

event-name 

= 

letter  digit? 

36- 

37- 

38- 

8. 

signal-statement 

SIGNAL  event-name 

59-  193.3 

AO- 

41-  2. 

42- 

43-  3. 

44- 

45- 

46- 

47-  8. 

48- 

49-  Statement  610  would  suspend  the  current  section  for  one  and  a 

50-  half  hours  < asst  i ny -aasisy  a t any  - i'lnpt--:^pii«iin^-TTf  nno  qrnnrtl-.  and 

51-  statement  620  would  suspend  the  section  until  the  time  'M  seconds 

52-  past  midnight’.  Statement  640  sets  the  event  Pi  to  ’true’. 

53- 
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1 - 193.4  Semant i c s 

2- 

3-  A START  statement  unconditionally  starts  a parallel  section  at 

4-  its  lowest -numbered  statement.  An  implementation  must  specify  the 

5-  action  following  a START  statement  for  a parallel  section  that  has 

6-  not  reached  a PAREN0  or  PAREXIT  statement  following  a previous 


7- 

8- 
O- 

activation.  The  scheduling  call 
error  condition. 

may 

be  queued,  or  it 

may  cause 

T 

10- 

11- 

A STOP  statement  terminates 
parallel  sections. 

the 

whole  program. 

including 

12- 


Examples 


/60 


6Q0^ST ART  PI 

610  WAIT  DELAY  = 1.5*60*60 
620  WAIT  TIME  = M*60 
1630  WAIT  EVENT  PI 

SIGNAL  PI 
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-13- 

14- 

-15- 

-16- 

-17- 

-18- 

-19- 

-20- 

-21- 

-22- 

-23- 

-24- 

-25- 

-26- 

-27- 

-28- 

-29- 

-30- 

-31- 

-32- 

-33- 

-34- 

-35- 

-36- 

-37- 

-32- 

-39- 

-40- 

-41- 

-42- 

-43- 

-44- 

-45- 

-46- 

-47- 

-48- 

-49- 

-50- 

-51- 

-52- 

-53- 

-54- 

-55- 

-56- 

-57- 

-58- 


The  expression  for  interval -cond i t ion  defines  the  number  of 
seconds.  The  expression  for  time-condition  gives  the  number  of 
seconds  past  midnight. 

An  event-name  is  either  the  name  of  an  interrupt  path  or  the  name 
of  a 'software'  event.  Software  event  names  are  not  declared 
explicitly;  they  are  declared  implicitly  by  their  occurrence  in 
SIGNAL  and  WAIT  statements. 

At  the  hardware  level  an  interrupt  condition  should  be  cleared  as 
soon  as  it  is  recognised  to  allow  other,  possibly  higher  proirity 
interrupts  to  be  accepted.  The  occurrence  of  an  interrupt  should 
therefore  be  remembered  by  the  system  until  the  corresponding  WAIT 
statement  has  acted  upon  it. 

Most  implementations  will  provide  control  statements  (see  section 
192.6)  to  enable  and  disable  specific  interrupts,  since  the  system 
may  include  potential  sources  of  interrupts  other  than  those  that  can 
be  serviced  by  the  program. 

A SIGNAL  statement  sets  the  associated  event  to  'true',  so  that 
any  section  waiting  on  that  event  can  continue. 


193.5  Exceptions 

For  some  implementations  the  execution  of  a START  statement  for  a 
parallel  section  thathas  not  reached  a PAREND  or  PAREXIT  statement 
since  a previous  activation  is  a run-time  error  condition. 


193.6  Remarks 
None . 


193.7  Inter-module  dependence 

There  is  a problem  of  identifying  a section  name  or  an  event  name 
passed  as  an  argument  to  a sub-program. 

193.8  Resolved  questions 
None 


~ 1'  19 '.9  Open  questions 

- 2- 


- 3-  Should  the  i nt erva l -cond i t i on  and  the  time-condition  be  an 

- 4-  expression  or  should  it  be  in  the  form  hours-minutcs-seconds?  Should 

- 5-  this  form  be  introduced  as  an  option  in  level  2? 

- 6- 

- 7-  Should  the  WHEN  clause  in  level  2 really  be  in  level  1?  It  is  not 

- 8-  difficult  to  implement  since  it  uses  the  same  operating  system 

- 9-  facility  as  the  WAIT  statement,  and  its  use  greatly  increases  the 

-10-  intelligibility  of  a program. 

-11- 

-1?-  A fundamental  question  is  whether  events  are  ’consumable'.  If 

-13-  they  are  not,  event  flags  must  be  cleared  explicitly  with  CLEAR 

-14-  statements,  so  the  three  operations  SET,  WAIT  and  CLEAR  are 

-IS-  necessary.  If  an  event  is  consumed  (the  correspond inq  event  flag  is 

-16-  cleared)  when  it  is  acted  upon  by  a WHEN  statement,  only  two 

-17-  operations  are  required,  referred  to  as  SIGNAL  and  WAIT. 

-18- 

-19-  SET-CLEAR  and  WAIT  is  a lower  level  approach,  similar  to 

-20-  semaphores,  in  which  the  user  has  more  responsibility  for  the  correct 

-21-  operation  of  the  system.  It  has  the  advantage  that  a WAIT  statement 

-22-  can  include  a list  of  events,  so  that  the  program  can  continue  when 

-23-  any  one  of  a number  of  events  occurs.  Since  the  events  are  not 

-24-  consumed  they  may  be  tested  in  IE  statements  to  find  which  one  caused 

-25-  the  program  to  resume. 

-26- 

-27-  SIGNAL  and  WAIT  is  simpler.  The  possibility  of  errors  due  to 

-28-  forget t ing.  to  clear  an  event  does  not  arise,  and  conceptually  it  is 

-29-  easier  to  understand  in  terms  of  the  plain  language  meaning  of  event. 

-30-  In  the  case  of  SET-CLEAR  and  WAIT  two  concepts  are  needed,  that  of 

-31-  the  event  itself  and  of  a flag  of  some  sort  in  the  system  that 

-32-  remembers  the  occurrence  of  the  event,  otherwise  the  notion  of  'clear 

-23-  event1  is  meaningless.  If  'wait  on  a list  of  events'  is  required,  a 

-34-  new  construct  such  as  ON  event-list  GOTO  will  be  necessary  to 

35-  determine  which  event  caused  program  continuation,  but  the  same 

-36-  result  can  be  achieved  by  setting  up  as  many  parallel  sections  with 

-37-  WAIT  statements  as  required,  each  of  which  calls  the  common  parallel 

-38-  section. 

-39- 
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OIT  PATTERNS  AND  LOGIC  OPERATIONS 


194.1  General  discussion 


In  BASIC,  numbers  are  usually  expressed  in  decimal  notation.  For 
real-time  applications  the  expression  of  bit  patterns  is  also 
required,  for  which  octal,  hexadecimal  or  binary  format  is  usually 
more  convenient.  By  analogy  with  the  VAL  and  STR$  functions  defined 
in  the  Strings  Enhancement  Section  22,  the  functions  OCT,  HEX  and  PIN 
are  used  when  a string  expression  is  to  be  interpreted  as  a bit 
pattern  in  octal,  hexadecimal  or  binary  format  respectively.  The 
functions  0CT$,  HEX?  and  BINS,  perform  the  conversion  from  a numeric 
value  (taken  as  an  unsigned  integer)  to  its  representation  as  an 
octal,  hexadecimal  or  binary  string. 


Bit  manipulation  is  a common  requirement  for  real-time  systems, 
for  which  the  logical  operations  AND,  OR,  exclusive-OR,  NOT  and  SHIFT 
are  rquired.  A shift  function  is  defined,  and  logical  operators  are 
introduced  for  the  other  operations. 


194.?  Syntax 

1.  bit-pattern-function  = 0CT/HEX/8IN/BIT/0CT$/HEX$/BIN$/SHF 


?.  bit-pattern-expression  = 


bit-primary  ( log i ca l -ope  rat  or 
bit-primary)* 


3.  bit-primary 


BITNOT?  (bit-pattern 

/open  bit-pattern-expression  close) 


4.  logical-operator 


= BITAND/BITOR/BITXOR 


194.3  Examples 

1.  700  LET  X = OCT("3?1") 

701  LET  X = BINC’1 101  0001") 

702  LET  X = HEX("t>1") 

2.  710  LET  X = HEX ("CO")  BITOR  (Y  BITAND  OCT("37")) 


If  Y has  the  value  17  decimal,  all  the  examples  set  X to  the 
value  decimal  209,  assuming  bit  patterns  are  interpreted  as  unsigned 
decimal  constants. 


i 


..  . . J1  . 


set  ; TzT^r  : 
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194.4  Semantics 

The  term  ‘bit-pattern*  in  rule  3 could  be  either  a bit-pattern 
expression  or  a numeric  value  interpreted  as  a bit  pattern.  The  bit 
pattern  corresponding  to  a numeric  value  is  taken  as  the  binary 
representation  of  the  modulus  of  the  integer  part. 


The  SHF  function  has  two  arguments,  the  first  is  interpreted  as  a 
bit-pattern  that  is  shifted  the  number  of  positions  equal  to  the 
integer  value  of  the  second.  A positive  number  specifies  a left 
shift,  a negative  number  a right  shift.  Zeros  are  entered  at  the 
appropriate  end  so  that  a shift  of  more  positions  than  the  number  of 
bits  in  the  pattern  returns  all  zeros. 

The  argument  of  the  BIT  function  must  be  a positive  numeric 
value,  the  integer  part  of  which  indicates  the  position  of  a *1*  in  a 
bit  pattern.  The  value  returned  for  the  function  has  a ’1*  in  this 
position  and  ‘O’  in  all  other  positions.  Bit  positions  are  numbered 
from  1 starting  with  the  least  significant. 


194.5  Exceptions 


The  argument  of  one  of  the  functions  OCT,  HEX  or  BIN  is  not  a 
valid  string  (for  example,  in  the  case  of  BIN,  it  includes  a 
character  other  than  0,  1 or  space,  or  it  requires  more  bits  than  the 
system  can  represent). 

A negative  numeric  value  is  presented  for  conversion  to  a bit 
pattern. 


-26-  194.6  Remarks 


The  functions  OCT,  HEX,  BIN  and  BIT  are  useful  in  program 
statements  including  DATA  statements,  and  for  input  from  the  terminal 
in  response  to  an  INPUT  statement. 

The  inverse  functions  are  most  useful  in  PRINT  statements. 


194.7  Inter-module  dependence 


None. 


194.8  Resolved  questions’ 


None . 


19<».9  Open  questions 


Should  the  data  type  'bit  pattern'  or  'bit  string'  (character 
string  representation  of  a bit  pattern)  be  introduced  for  logical 
operations?  Without  a bit  pattern  representation,  logic  operations 
require  automatic  conversion  between  the  floating-point  form  and  the 
bit-pattern  form,  which  could  be  very  time  consuming.  If  bit 
patterns  are  introduced,  are  implied  type  conversions  allowed  or 
should  the  functions  FIX  and  FLOAT  be  defined  for  explicit  type 
conversion. 

i 

Can  the  reply  to  an  INPUT  statement  be  typed  in  octal, 
hexadecimal  or  binary  form?  If  so,  is  this  pre-determ ined  in  the 
INPUT  statement  or  can  the  bit-pattern  functions  be  used? 


<*mm  1 


sn 
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ELECTROTECHNICAL  LABORATORY 
TANASHI  BRANCH 

5-4-1  MUKODAI-MACHI,  TANASHI-SHI, 

TOKYO,  JAPAN 
TELEPHONE:  0420  (6t>  2141 


November  25,  1977 

Prof.  Theodore  J.  Williams 
Purdue  Laboratory  for 
Applied  Industrial  Control 
102  Michael  Golden 
Purdue  University 
West  Lafayette,  Indiana  47907 
U.S.  A. 


Dear  Prof.  Williams 

It  was  very  nice  to  meet  you  at  IPW  meeting.  We  have  had 
several  meetings  of  IPW-  J since  I came  back  to  Tokyo. 

RT-  BASIC  WG  had  investigated  about  Industrial  BASIC  Level  1 
and  Level  2 Enhancement,  and  offered  some  comments  to  Iondon 
Meeting.  Enclosed  please  find  a copy  of  those  comments.  And  also 
please  find  a copy  of  report  which  Microcomputer  WG  discussed 
about  our  activities  hereafter. 


Sincerely  yours, 

1 J/sl  A <r\ 

Koji  Yada 
Computer  Center 


ffUCCSDINQ  FJOB  BUUlK 


November  2,  1977 


Comments  made  by  Japan  Real-Time  BASIC  Committee  on 
the  Comments  of  IHTB-  E/77-17  (level  1 1KTB) 
which  had  been  given  by  Dr.  Bull. 


Koji  Yada 
Chairman 

Real  Time  BASIC  Committee  IPW-J 


The  members  of  Japan  Real-Time  BASIC  Committee  have  discussed  on 
Dr.  Bull's  comments  of  IRTB-E/77-17  (level  1 IRTB)  and  agreed  to  the  most 
of  his  comments.  But  there  have  arised  some  questions,  different  comments, 
and  additional  comments,  which  are  described  as  follows. 


Comments 


2.  p4  1 1-7 

If  every  parallel  section  has  its  own  pointer,  it  may  be  better  to  change 
the  syntax  in  order  to  reduce  the  interpreter's  responsibility. 

4.  p5  1 -51 

Just  the  same  commnet.  Is  whole  siutax  left  to  the  system  manufacturers? 

13.  p8  syntax 

Why  5 write-item=  read -item/expression  should  be  5 write-item  = expression? 

14.  plO  1-32 

Why  should  it  be  6 event-name=EVENT  (event-name/path  name)?  Is  event- 
name  the  mistake  for  event- condition ? 


Additional  Comment  for  the  London  Meeting 

Dec  statement  should  not  tie  statement  command  but  control  command 
in  order  not  to  be  changed  in  application  programs. 


■ 
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CHAPTER  IV 


REPORTS  OF  THE 

LONG  TERM  PROCEDURAL  LANGUAGES  COMMITTEE 


The  following  documents  are  included  here: 


Minutes  of  the  LTPL-C  Meeting  at  Purdue  on  October  3-6, 
1977. 

Minutes  of  the  34th  Meeting  of  LTPL-E,  Brussels, 

September  15,  1976. 

Minutes  of  the  36th  Meeting  of  LTPL-E,  January  31 -February 
2,  1977. 

Minutes  of  the  38th  Meeting  of  LTPL-E,  Brussels,  June 
1-3,  1977 
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LTPL-C/?  ? 
77/11/07 


To: 





LTPL-C  Mi'mbcrs 


77/11/07 

Alex  J Arthur 

ION  Corp,  M77/G2 0 

555  Bail  oy  Avo 

San  Jose,  CA  95150,  USA 


I 


i! 


i 


I 


LTPL-C  Meeting  at  I n t or  na  t l one  1 Purtlup  Workshop  Mooting,  77/10/3-6 


The  mooting  was  called  to  ordor  by  Potor  Elzer,  Chairman  pro  tom.  Tho 
consolidated  list  of  attendees  at  all  sessions  is  enclosed. 

0.  Tho  enclosed  agenda  was  agreed  on. 

1.  The  minutes  of  the  previous  meeting  were  approved  without  change. 

2.1)  A short  report  on  the  activities  of  the  LTPL-A  was  given  by  Alex 
Arthur. 

The  LTPL-A  has  met  3 times  since  the  last  LTPL-C  meeting.  The  main 
work  of  the  committee  has  been  to  do  a detail  critique  on  the  DoD 
IRONMAII  document.  The  results  of  that  review  have  been  forwarded  to 
DoD.  Otherwise  the  committee  has  done  some  work  on  the  qreen  sheets  and 
has  had  a joint  discussion  with  TC-1A  on  tasking.  The  future  meetings 
of  tho  LTPL-A  are  in  January,  7o(San  Diego  - joint  meeting  with  TC-1A) 
and  at  the  Spring  Americas  Regional  WorkshopC  Purdue)  in  April  of  7S. 

2.2)  A report  on  the  LTPL-E  activities  was  given  by  Peter  Elrer.  LTPL-E 
has  had  3 meetings  in  full  session  in  the  last  year,  January ( Brussel s ) , 
Apr l 1 ( Ispra ) and  June < Brussel s ) . The  proposed  September  meeting  has 
been  postponed  until  October  17-19.  further  meetings  are  scheduled  for 
end  January  1 97S < Brussel s ) and  at  the  Spring  Regional  Workshop 
meet l ng<  Zur i ch ) . 

Tho  subgroup  participated  in  a DoD  IIOL  meeting  at  I . D . A . ( Wash l ngt on ) in 
July  of  this  year. 

A caucus  mooting  of  the  tasking  subgroup  took  place  on  September  19-20 
(Brussels).  The  participants  were  Timmesfeld,  Wand,  Kronrnt.il  and 


This  Wiis  onr>  of  tho  first  mootings  undrr  a new  custom  which  LTPL-t  is 
trying  to  establish.  It  is  to  have  intensive  working  sessions  of  the 
working  groups  to  produce  consistent  write  ups. 


The  3 main  aspects  of  tho  past  year’s  work  have  boon 

A)  produce  papers  for  tno  CEC’rhnir  and  planning  group) 

1 ) mu  ]or  propose  1 
ii ) snapshot  report 

ill)  prioritised  list  of  urgent  work  items 

D)  monitor  in  ci  DoD  effort 

l)  comments  by  individuals 

ii ) papers  for  DoD  briefing  sessions 

C)  detail  work  on  LTPL 

l ) tasking  group  is  well  along 

ii)  algorithmic  group  is  not  so  far  along 

ill)  I/OCProf  Verroust  — chair) 

iv)  evaluation  criterinlcliiiir  and  scope  of  work  problems) 

These  last  2 are  suffering  from  staffing  problems. 

v)  system  description  - important  but  has  not  started  due 

to  understaffing  of  others. 


Mr  Roh  has  got  a lot  of  material  for  FLIP  purposes. 

For  the  next  international  meeting,  LTPL-E  hopes  to  have  a major  paper 
on  the  state  of  the  art. 

2 aspects  can  be  split  off 

1)  DoD  HOLWG 

2)  Program  Development  Tools  - i.e.  things  beyond  the  language. 
The  chair  is  attempting  to  got  a subgroup  started  on  this  last. 

Some  discussion  was  held  on  mailing  problems.  Peter  said  he  would 
remind  his  members  of  the  problems.  He  then  discussed  the  now  numbering 
scheme  which  they  have  been  forced  to  introduce  due  to  communication 
problems  and  costs.  Some  queries  about  the  possibility  of  using  the 
ARP  A net  for  such  purposes  wore  made  but  Col.  Whitaker  pointed  out  that 
such  was  not  tho  net's  purpose  and  tho  postal  authorities  in  UK  and 
Germany  would  bo  reluctant  to  approve  of  such  a use. 

2.3)  There  being  no  representative  present  from  LTPL-J,  mention  was 
simply  mode  of  JEIDA  report  52-A-117  and  a letter  from  Mr  Sudo  re  his 
resignation  as  LTPL-J  chair  and  the  addresses  of  the  relevant 
individualsfpreviously  distributed) . 

3.  Merritt  Adams  presented  a sot  of  foils  on  the  status  of  TC  97/SC  5/NG 
1 (FLIP  ) . 

- Brief  History  and  Background 

- Agenda  of  London  meeting 


US  delegates  advocate  support  of  ISA  S61.1  and  S61.2. 
Jones:  Why  CORAL  rather  than  PTL/2? 

Harrison:  We  don't  know. 
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Short  i'r : Thoro  it.  .1  UK  govrr  nrnen  t pro  j ec  t to  support  CORAL  BSI  PPS 

13  it.  going  to  sond  out  'CORAL  66'  plus  clan  fictitious.  HG2 
it.  now  processing  PTL/2. 

Tho  113  do  1 eg.i  t es  ,ilso  .idvoc.it  o submitting  upd.it  rd  green  sheets  .ind  tti-.t 
tho  Workshop  support  submission  of  IROHMAM. 

Thorn  .iro  3 p.ipor  s already  submitted  by  tho  US  Jilivj.iti". : one  is  1 
rpspontiii  to  tho  FORTRAN  commentary  documents,  and  two  .ire  relative  to 
the  lunction.il  roqui  roments  ‘.t.ilement.  The  lirst  01  t liesr  refer:,  to  the 
Munich  paper  with  concern  and  the  second  is  a dist.nl  critique  ot  the  BSI 
document  Tint.  last  document,  the  BSI  submission,  is  lelt  by  the  US 
delegates  to  be  an  excellent  piece  of  work  and  sets  a very  high  standard 
lor  tho  other  delegations  to  emulate. 

A fourth  paper  is  ready  lor  submission  and  a draft  ol  it  lias  been 
Circulated.  The  final  version  will  be  prepared  after  the  USTAG 
meet  1 ng< 77/ 1 0/A > . The  paper  addresses  CORAL  06  and  suggests  it  be 
dropped  from  further  cons  1 dor  a t 1 on  as  ltfas  sped  find  in  document  N20) 
does  not  satisfy  the  criteria.  Although  N20  plus  some  extensions  might 
he  functionally  OK  there  would  ihon  be  some  concern  about  the  extent  of 
use,  etc. 

Elzor:  I input  the  LTPL-C/E  functional  requirements  to  the  TIN  effort, 
(see  1 tom  3 on  3rd  last  page  referencing  N36). 


need  to  update  and  consolidate  our 


Elzor:  It  would  appear  that  we  need  to  update  and  consolidate  our 

1 unc  t 1 on a 1 rnqu 1 r omen  t s . 

There  was  then  much  discussion  which  eventually  reached  the  conclusion 
that  this  should  be  done  and  that  we  should  do  it  by  tracing  all  our 
past  documents  onto  a skeleton  format  derived  Irom  IRUNMAN 

A.  Cel  lihi taker  summarised  the  OoD  f I OL  history  and  status  as  follows. 

The  effort  is  really  a ' commona 1 1 t y ' effort  rather  than  a standard:, 
effort.  It  is  specifically  directed  to  'embedded  computers',  that  is, 
computers  used  in  Weapon  Systems,  Communications,  Command  and  Control. 
Avionics  and  Simulators.  DoD  has  a very  high  software  cost  lor  such 

machines  and  commonly  has  to  support  them  for  many  your s after  their 

initial  introduction  into  service  including  development  work  to  update 
or  change  the  mission.  Col  Whitaker  pointed  out  that  he  had  carefulls 
not  used  the  word  maintenance  for  this  activity  as  the  DoD  experience 
was  that  in  reality  programs  are  not  'maintained'  in  the  sense  that  that 
word  suggests  to  everyone,  except  programmers,  but  rather  programs  are 
subject  to  continuous  r edevel opmon t . 

Directive  5000.31  allows  only  the  use  of  C0B0L-7A,  F UR TR All- 66 . CMS-2 , 
SP  L - 1 , TACPOL,  and  JOVIAL  J3  and  J~3.  The  '5000  ' series  of  directives 
are  „11  concerned  with  embedded  operations.  In  response  to  a guest  ion, 

Col  Whitaker  confirmed  that  P L I is  NOT  on  that  list.  It  is  apparent  1> 

on  an  ADP  list. 

The  project  was  initiated  by  terming  the  HOI.  WG.  Their  first  task  was 
to  formulate  requirements.  In  synopsis  their  requirement  list  was  as 
foil ows . 

- Modern  H0L (don’t  need  ANY  machine  language) 

- need  Programming  Tools  to  support  the  language 

- common  HOLs 

- minimal  number 

- single  common  DoD  H0L  looks  feasible. 
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The  TINMAN  document  was  fully  blessed  by  nil  of  the 


The  successful  contractors  vat. 
Softech  and  5RI,  Internal  1 onul . 
just  the  way  it  turned  out.  The  r 
3/77  Design  Contracts 
A/ 73  Phase  1 Selection 
4 / 79  Final  Selection 
1930  Language  Availabli 


were  C 1 1 -Honeywel  1 -ttu  1 1 , Intcrmetrus, 


All  A were  PASCAL  based  but 
hociu  1 0 is 


that  iia' 


It  is  not  y 

ct 

clear  whether 

this 

1 ast 

Mill  i nc:  1 ude 

adding  t h 

t*  1 «m  gu  «ig 

to  the  5000. 

31 

1 1 !.  t .it  that 

t 1 me  . 

On  October 

20t 

h,  reports  wi 

1 1 be 

made 

on  i oiMnrmn: 

« 1 n 0 1 > sos 

1 jh  1 i;h  i«ii 

procood 1 ng 

semi  - 1 ndeponden t 

ly  . 

r h 1 s 

1 s not  norm 

.1 1 for 

.1  proj-s 

expend 1 turo 

O 1 

this  1 ON  cl 

volume 

bn  t 

it  is  frit 

th.it  tho 

1 inp.tr  * 1 

potentially  great  enough  that  it  is  worth  doing.  The  questions  thesi 
analyses  are  attempting  to  answer  .ire; 

Is  1 language  very  much  less  costly  than  7,  how  can  a new  language  bi 
best  phased  in,  what  are  the  trade  oil;,  in  terms  of  savings  versus  cost' 
and  difficulties  and  where  should  the  expenditures  be  concentrated? 


The  DoD  MOL  WG  1 s now  beginning  a non— language  requirements  analysis. 
The  STRAWMAN  document  for  this  has  just  been  typed,  WOOPENMAN  is 
expected  by  7S/1/1,  TINMAN  by  the  fall  of  73  and  there  will  be  an 
IR0NMAN  beyond  that.  Comments  ,,nd  input  from  LTPL-C  would  be 
appr  ec 1 a t ed . 

Dol)  MOL  WG  has  scheduled  meetings  on  the  subject  in  January  and  June  of 
7$.  Some  of  the  questions  are  how  should  the  compilers  for  tin?  language 
be  written,  should  separate  compilation  be  supported  and  what  should  the 
format  and  style  of  the  error  messages  be? 

By  77-Decembei — 1 , DoD  MOL  WC-  has  to  formulate  benchmarks  to  test 
des 1 gns  aga 1 ns  t . 

DoD/ 1 is  the  project  name  but  so  tar  there  is  no  lnnguaqo  name.  One 
has  to  ho  selected  by  7S  February  1.  Suggestions  are  welcome  and  should 
be  sent  to  Lt.  Col.  WA  Whitaker,  DARPA,  1,00  Wilson  Blvd.,  Arlington,  VA 
22109. 

In  answer  to  a question.  Col  Whitaker  indicated  that  typically  these 
systems  are  rewritten  every  3 to  7 years. 


4a . As  PASCAL  is  the  base  languaqe  of  all  the  successful  bids  on  the  DoP 


MOL  project,  many  committee  members  had  expressed  interest  111  knowing 
more  about  the  language.  particularly  from  someone  who  had  some 
practical  use  of  it.  Stephen  Schwerin  volunteered  to  present  a summary  of 
the  language  plus  some  comments  on  his  experience  with  it.  111?, 
presentation  follows. 

He  has  been  using  the  language  experimentally  for  software  tool;,  and  as 
a design  language.  The  best  users  guide  is  the  Jensen  S Mirth, 
Spr 1 nger-Ver lag  book,  student  edition. 


Sf  inrlard  T_vp_es  and  Opera  t i ons  all  owed  oil  t hem 


Enumerat  1 on  ( BOOLEAN  . CHAR  ) compnr  1 son  (>,  = ,-,=  ,<) 

R an get  1 NT EGER  > comparison  + , - , * , DI V ( t r unco t ed ) , MOP 

REAL  comparison 

Pointertnll  point  to  typo)  compnr  1 son  ( = ,-,=  ) 


n 


f 
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r 


riLE 

SET 


1 n c 1 u r.  ion,  + ,- 


Comp  1 ox  T\j"u*s 

ARkA"!  I r angot  , r aikjo>  « ] OK  T 


k or  or  d 

RECORD  T 1 ; T 2 ; . . . CUD 

or 

RECORD 

CASE  name:  pnumcration  OF 
<1  ; ( name  1 : T 1 ; n ainoZ  : T 2 > 


END 

S t .1 1 1'mi'n  t ■ . 

Notes:  S l r>  a st  at  omen  t ( can  use  DEGIN;...  END  in  place  of  S). 
B a boolean  expression. 

separates  statements. 

Assignment  o.g.  X :=  V 

IF  B THEN  S (ELSE  S) 

WHILE  B DO  S 

FOR  I :=  ini  t To|dOHMTO  final  value  DO  S 
REPEAT  S <;S>  UNTIL  B 
CASE  enumorat  i on  variiiblu  OF 
val  uol  ; S 
va 1 ue2 : S 


END  (most  implementations  support  OTHERWISE) 

MI TH  record  DO  S 

o.g.  TYPE  X = RECORD 

B ; INTEGER ; 

C: REAL ; 

END; 

VARIABLE  Y : X ; 

normally  must  say  Y.B  :=  1 
after  WITH  Y DO 

can  simply  code  B :=  1 and  the  value  of  Y.R  is  set  to  1. 


Input.  Output 


TYPE  X = FILE 

OF  T 

VARIABLE  Y : X 

( Y is 

file 

pointer) 

(can  do  reset , 

, r ewr i t e , 

i get  , 

put  ) 

RESET 

open 

back  to  start  o.g.  RESET(X) 

REWRITE 

opo  n 

empty 

Z :=  GET ( Y ) 

next 

record,  char  or  integer 

■ 


I 


I 


\i 
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IThiro  are  TEXT  files.) 
READfF .CHARA, INTI ) 
NPITEfF. CHAPA:  1 , INTI r 5 > 
RE ADLN 
NR  I TELH 
EOLN( f ) 

EOF ( f ) 


looks  tor  character  then  numeric  Field:. 
1 space  followed  hy  5 character  spaces 


T rue  1 f end  of  1 l net l . o bl ank  ) 
False  o t her w i s n 
T rue  l I end  of  tile 
False  o t herw i se 


P r phi-  ,i in  Structure 


P R OCR  AM  name  < . . . test  files...): 

Const  an  t sec  t i on 
Tvpc  sect l on 
Variable  section 

procedures  name ( par  amet  or  — list  ) 

.i  1 1 parameters  must  be  typed 

all  calls  are  by  value  unless  insert  VAR  to  make 
t hem  call  by  name 

fund  i on'.  Ireturn  any  standard  type). 


Scope  Rules 

within  procedures  everything  but  statically  defined 
.ill  implementations  are  recursive 
mainline  program  starts  with 
begi  n 


end . 


Arthur:  Is  there  reference  inhcri  t.inci1? 

Scliwarm:  Yes 

Shorter:  Nh.it  about  errors  on  I/O? 

Schwarm:  implementation  dependant 

Gertler:  How  does  NHILE  work’ 

Schwann:  Test  is  at  beginning  of  code  block. 

Brewster:  Is  there  any  kind  of  cert  l f i cat  l on/st  and.irdi  sat  i on  group? 

Schwnrm:  There  is  PUG.  Andv  Micheals.  University  of  Michigan.  The 

language  is  well  defined.  Compilers  are  normally  written  in  PASCAL. 
Many  of  them  are  derived  from  the  same  compiler  which  defines  a P-code 
inach l net st ack  arch i tect ure . character  representation).  It  took  us  about 
1 man  month  to  get  it  up  and  running.  It  would  have  been  only  about  1 
week  if  we  had  not  run  into  some  special  problems.  The  language  is 
designed  for  a single  pass.  The  compiler  compiled  ltselffAIOO  lines)  in 
12  minutes  th’n  we  had  a 2 hour  assembly.  There  is  a new  compiler  from 
LM  Ericson  which  is  a direct  code  generator. 

Elzer:  Why  so  popular’  Files  seem  primitive*! 

Schwarm:  Nothing  special  in  control  structures  but  it  is  special  in 
data  types  and  i s small  enough  to  learn  rapidly. 

Elzer:  ASK  does  not  seem  really  small!  What  about  run  time  support? 

Schwarm:  get  put  etc  has  to  be  written  but  these  primitives  are  simple 


k 
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.ind  c otnp i lor  breaks  complex  cxpriv 
Whitaker:  A major  advantage  1 

de  f 1 n 1 t 1 on . 


.ions  down  into  simple  ones, 
i th.it  there  exists  .in 


a > l om.i  t i c 


t . 
t o 


implemented  ,e 
e l t her  I 


<1 

he 


5.  hr.  Gertler  g.ivo  a presentation  on  real  time  APLfsee  enclosure). 

Note:  The  reported  work  nas  done  at  the  Chemical  Engineering  Department 
ol  C lse  Western  Reserve  University,  Cleveland,  Ohio,  with  the 
p.ir  t l c i p.it  i on  of  Dr.  Adi  n J.  Mann  and  Dr.  Robert  V.  Edwards  under 
research  grants  from  N I H ( Genera  1 Medical)  and  ERDA. 

In  the  discussion  Which  followed  Dr.  Gertler  emphasised  that  their 
objective  was  to  select  a ’ r eas  on.lb  1 e ’ set  of  tasking  facilities.  He 
does  not  really  believe  that  there  l s such  a thing  as  a complete  li' 
They  do  intertask  communication  using  shared  variables  but  need 
modify  their  scheme  further  to  allow  multiple  workspaces  to  share. 

E 1 zor : How  difficult? 

Uor tier:  not  too  difficult  as  long  an  the  tasking  is  kept  simple. 

Brewster:  What  about  hardware  names? 

Gertler:  An  assembler  written  system  routine  is  used 
We  did  not  want  an  automatic  update  facility  for  input 

Lopcr:  Wh.it  fixes  did  you  do  to  the  interpreter? 

Gertler:  Hone  yet!  The  communication  processor  is 
pseudo  shared  varaible  processor  and  sends  instructions  to 
real  tune  front  mid  or  the  host  as  required. 

Arthur:  In  essence  then  the  communication  processor  acts  as  a 

preprocessor  for  the  interpreter  and  lilt1  front  end? 

Gertler:  Yes,  tii.it  is  one  of  the  di  f ferencos  between  what  I am  doing 
and  what  I am  proposing. 

Brewster:  APL  is  a poor  document  at i on  tool.  llhat  about  maintenance? 

Gertler:  I have  no  personal  experience  of  API.  outside  this  group.  True 
ir!lk  1 s prim.in  1 y meant  f or  the  mom  en  t not  f or  ntcrni  tv  but  l f one  uses 
functions  properly  can  get  quite  good  documentation. 

Eller:  Should  you  discriminate  between  Hardware  and  Software  functions 
in  I/O?  Suppose  the  software  function  migrated  into  hardware’ 

Also  event  hanJling  is  equivalent  to  interrupts  so  would  it  not  lie 
better  to  have  a static  link’ 

Gertler:  In  answer  to  your  first  question.  let  me  clari tv  what  we  mean 
by  hardware  and  software  functions.  Hardware  functions  are  for  example 
things  like  code  conversion  from  an  ADC  or  program  suspension  for  1 0, 
software  functions  are  things  like  corrections,  conversion  to 
engineering  units,  etc. 

Elzer:  You  mean  tilings  more  like  ’logical*  transformations  than 

’system’  transform a ti o n s ? 

Cert ler: Yes,  as  to  your  other  comment,  some  events  are  always  handled 
by  routines  anyway  so  it  seems  more  logical  to  always  go  thru  routines. 

Shorter:  Why  is  only  assignment  allowed  to  output  variable's? 

Gertler:  Readb.ick  is  really  a different  variable. 

Shorter-:  But  the  set  point  is  often  needed! 

Gertler:  True  that  could  be  a useful  feature. 

Brewster:  That  can  be  dangerous  as  people  confuse  output  value  with 
actual  value.  One  might  well  require  a 3 tiered  system. 

Schwann:  Ho  provide  an  explicit  function  to  do  a readb.ick. 

Elzer:  I am  concerned  about  the  use  of  process  variables, 


uses  them  .in  an  expression  it  seems 
operation  Without  realising  it. 


though  you  could  get 


I I OIK' 

an  I 0 
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Gortlor:  Wo  lcsvc  this  as  a user  r espons i bi 1 t y . 
yeor  deb.iti;  in  the  industry  on  this  with  no  firm 
compromised  a little  hero  ns  the  u'.or  does  have  to 
E 1 2 o r : Whnt  .ibout  rend  ond  clear? 

Gertler:  I nssumo  the  v.,luo  disappears  once  rend. 
Elzer:  But  CAMAC  provides  rend  ond  rend  ond  reset 
Gertler:  Wo  hove  not  dealt  with  that.  One  c: 

hardware  function  for  that  discrimination. 


There  has  been  a 10 
conclusions.  W«  have 
use  a special  symbol. 


d l s c r l in  i n a t i on  ! 
ould  probably  use  a 


6.  Joint  Session  on  Tasking  witti  TCI. 


Elzer:  IRONMAN  is  a qood  base  document  to  work  with  but  we  have  a lot 
of  relevant  internal  documents  to  fold  in  to  the  work. 

Whitaker:  One  must  keep  clearly  in  mind  the  difference  between 

functional  requirements  and  detail  specifications. 

Gor don_C 1 a r k : We  have  defined  some  necessary  functions  in  some  ot  the 
ISA  standards. 

The  committee  then  proceeded  to  allocate  the  various  documents  against 
the  IRONMAN  table  of  contents.  The  results  of  that  allocation  are 
enclosed.  A decision  was  then  made  to  have  the  various  subcommittees 
analyse  these  documents  and  prepare  material  fron  them  for  a new 
document  with  initially  the  same  TOC  as  IPONMAN.  The  allocation  was 
made  by  TOC  section  as  follows: 

LTPL-E  evaluation  criteria  subgroup  1, 

LTPL-E  algorithmic  subgroup  3, 

LTPL-E  I/O  subgroup  o 


12  and  13 
A , 5 , 6 and  7 


LTPL-E  tasking 
LTPL-A 


9 and  10 

9 and  10  and  1 , 2 and  ? 

(much  relevant  material  for  1,  2 and  3 is  in  the  past  minutes  of 


the 


LTPL-A)  . 

Col  Whitaker  reviewed  his  report  to  the  LTPL-C  for  the  benefit  of  the 
TCI  members. 

1.  Evaluation  of  Phase  1 efforts  will  be  the  first  3 weeks  in  March. 
Represent  .it  l ves  of  the  committees  will  he  invited. 

2.  Benchmarks  must  be  done  by  December  1. 

3.  'Sandman'  environmental  requirements  are  due  by  December  - input  is 
so  1 i c i ted. 

A.  The  languaqe  needs  a name. 

5.  3 economic  analyses  are  in  progress. 

a.  MITRE  - first  to  be  passed  on  - counting  systems  world  wide,  etc. 
Failed  - crude  but  right  answer.  Benefits  considered  wore  only 
training,  tools  and  technical  advance.  The  total  analysis  will  be 
presented  to  the  management  steerinq  committee  on  October  20. 

b.  DDI  - 2 portions-  a decision  scenario  and  a technology  analysis 

in  great  detail.  Both  are  being  done  on  a desktop  coinputerflBM  5100)so 
have  some  problems  with  regard  to  updating  and  alternative  scenario 
analysis. 

c.  DoD  HOL  WG  - similar  approach  to  DDI  but  on  APPA  not.  Really  a 
scenario  generator.  Comes  up  with  a value  and  shows  technical  benefits. 
Commonality  shows  as  cost  avoidance.  It  exists  as  a FORTRAN  program  on 
a DEC/10  and  WG  will  continue  to  support  it. 


Mathew  Gordcn-Clark  then  presented  the  current  state  of  the  TCI  work. 

A discussion  took  place  on  the  difference  between  'event-mark'  in  the 
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Fortran  document  and  • semaphore  * . There*  was  some  concern  expressed 
about  the  11  parameters  on  the  $ h E P routine.  The  European  document  use*, 
semaphores  but  allows  them  to  be  incremented  h\  greater  than  1. 

Common  i t enr,  were  l dent  i Mod  and  can  be  soen  in  t ho  5 routines,  CLREM, 
SC  T EM , TESTFM,  PKESEM  and  RDSEM. 

Ih  Me;  Can  you  do  event  combi  n»it  l on*.  ' 

Gar  don- C 1 a r I,  : No,  not  within  Fortran  constraints  as  event  inarms  are 
evaluated  to  scalar  integers  and  -.o  .in  event  mark  expression  cannot  be 
wr i t t en  in  subroutine  but  we  need  to  think  about  it.  Only  one  we  have 
thought  about  so  far  is  a simile  event  mark  plus  time.  The  Europeans 
will  look  at  more  than  tasking.  No  new  work  has  been  done  on  the  state 
d l ayr  am . 

Witte:  Is  the  state  diagram  equivalent  to  a Petri  net  0 

Gordon— Cl  ark  : I wouldn’t  know  a Petri  n •*  t if  I fell  over  it! 

Clzer:  GMlKWeqner)  has  done  work  on  Petri  nets  for  these  type  of 

capab i 1 l t es . I tried  to  introduce  them  to  L TP  L — E . Petri  made  a good 
presentation  to  the  L T P l -E  C enr  1 oMir  **  to  January  76  minutes). 

Petri  nets  have  3 major  elements  - pro  conditions,  transitions  and  post 
conditions.  The  drawing  for  any  practical  problem  yets  huge*. 

Gordon  — Cl  ark : If  Pruno(Witte)  thinks  it  would  be  valuable  to  try  to 
express  the  state  diagram  t h i s way  I would  l l k e to  encourage  him. 

Elzer:  Petri  said  * such  system:,  cannot  be  stable  without  feedback’. 

Gortler:  If  an  event  is  cleared  by  the  system  then  it (the  svstem)  can 
detect  reuse  of  the  event.  On  overrun  either  automatically  do  one 
t h l ng< ncql ec t it  or  create  a new  activation)  or  give  the  programmer  .in 
opt i on . 

Elzer:  We  need  to  give  the  programmer  choice. 

Gortler:  An  event  is  a binary  change  in  the  physical  environment  which 
lasts  for  a while.  The  system  must  have  a dynamic  representation  which 
can  be  reset  even  while  the  physical  event  is  not  reset , e . g . limit 
swi t ches . 

Elzer:  Event  marks  arc  really  for  interaction  between  internal  and 

external  proc ess. 

There  then  followed  much  discussion  of  multiple  events  and  multiple 
i n v oca t i ons . 

6.1  Operating  Systems 

Some  discussion  took  place  on  the  perennial  subject  of  whether  a 
language  such  as  the  I TPE  is  required  to  be  usable  in  the  writing  of 
operating  system*... 

Whitaker:  The  real  requirement  is  ease  of  ur itinn  applications  and  easy 
use  of  operating  systems. 

Loper:  Operating  system  correctness  is  important.  We  have  had  ‘.cine 
requests  for'  '..poci.il  data  types  relevant  to  operating  systems  but  so  far* 
have  rejected  them. 

Jones:  There  seems  to  bo  a contradiction  here  between  the  desire  to 
allow  the  operating  systems  programmer  full  access  to  the  machine 
resources  and  vet  to  protect  against  the  accidental  use  of  such  features 
by  the  application  programmer. 

Elzer:  I uoulc/  like  members  to  think  about  this  and  to  please  write 
some  papers  on  the  subject.  The  majority  of  the  LTEL-E  seem  to  feel 
that  it  can  only  be  solved  by  such  devices  as  locking  off  parts  of  the 
1 anguage . 

Loper:  That  i s m\  bn*  ic  concept  but  I think  it  should  be  possible  to  do 
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so  on  a vi>ry  line  level  ol  di'.crinnnatioii. 


It  was  nnnounced  that  Merritt  Adams  was  Hilling  to  tie  10m 
chairman.  There  were  no  obje<  honii  nor  were  there  any  other 
He  was  con  tinned  by  ,h'i1,iii),i  t i eii. 

3.  The  encleied  report  to  the  Wort  hop  was  drawn  tip. 

t* . A qucii  t i on  was  r a 1 t E l ;tT  ) .is  to  whether  the  commit  to 
review  or  discuss  the  outcome  ol  the  TCOr/SCb  II 0 1 USTAG  meeting 

decided  not  to  as  th.it  was  pi an  advisory  ciroup  nnd  it 

th.it  the  US  delegates  to  UG1  ha  J not  vet  met  together  to  r 

USTAG  meeting. 

10.  There  being  no  other  business  the-  meeting  was  adjourned. 
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LTPL-E/256,  L f r L-E /2  72  , LTPL E/27S,  L TP  L-E /375 , LIPL-C/376,  LTPL-E'350 

2.  Goncral  Syntax 
LTPL-E/309.  LTPL-E/350 

3.  Typos. 

Croon  shoots,  X3J3-C2S3.  X3J1'636,  Document  T,  LTPL-E/06S, 

LTPL  E/233. LTPL-E/309,  LTPL-E/350 

6 . Express  1 ons 
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6.  Control  Structures 
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9.  Parallel  Processing 

Green  sheets,  ISA  $61.3(1),  TC-1A  Gordon-dark  76.i0.1  76.11.16 
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10.  Exception  Handling 
Document  T 
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TechnLcal  Plenary  Meeting  J 6. 9 . 76 


Alter  chairman's  welcome  the  agenda  was  begun. 

Tl . Approval  of  Agenda 

The  chairman  added  an  item  B5 : Approval  of  sell  representation. 
Old  B5  becomes  Bb  etc. 

Item  T '±  had  to  be  removed.  A description  of  ILIAD  should  be 
sent  for  all  A-list  members. 

Mr.  Roberts  suggested  discussing  distribution  problems. 

Postpone  to  A.O.I),  Business  Meeting. 

Mr.  Chalmers  raised  question  of  distribution  of  August  planning 
group  proposals.  Chairman  suggested  taking  this  under  B2. 

The  chairman  asked  new  members  to  introduce  themselves. 

Two  new  members.  No  representative  of  DOD. 

T2 . Description  of  MOR Ab/Masco t 

Ha r t e : The  MORAL  manual  will  be  distributed  to  the  subgroup  chairmen 
so  the  technical  content  of  Mr.  Harte's  presentation  is  not  fully 
minuted.  Only  the  discussion  is  minuted,  in  detail. 

MORAL  means  MASCOT  oriented  reliable  applications  language. 

It  is  designed  as  a high-level  language  near  the  level  of  Algol-68 
but  which  translates  into  CORAL-66,  which  accounts  for  some  features. 
A Mascot  system  is  a system  of  parallel  activities  communicating  via 
unprotected  POOLS  (for  e.g.  read  only  dictionaries)  and  protected 
CjLANNELS  which  allow  for  synchronization.  Synchronization  is  via 
"control  queues"  which  are  seina/event  devices  with  primitives,  join 
leave,  wait,  stira.  (=  secure, release,  wait,  signal). 

The  idea  of  having  MORAL  is  basically  to  have  a clean  interface 
to  the  MASCOT  control  structures. 

MORAL  has  a LOCK  facility  (illustrated  in  the  example)  allowing 
elements  within  a group  to  he  protected  from  access  outside  the  group 
This  can  be  a total  ban,  for  protected  data  needed  only  by  procedures 
within  the  group,  or  partial  in  which  case  the  correct  key  must  be 
presented  by  the  accessing  procedure.  OKOI'PS  are  more  than  Alcol-Os 
STRIJCTS,  since  they  can  contain  procedures,  but  they  arc  not  In  1 1 
monitors  since  they  don51  automatically  exclude  one  another.  The 
enclosed  example  shows  the  use  of  the  Masco L primitives  in  MORAL. 
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T3 . Presentat  ton  of  Paper  351  on  Modnla 

Wan! : I'nl'or  tuna  t.ely,  Paper  35 1 has  not  been  distributed. 

MODI  LA  is  a new  language  developed  by  Pr.Wirth  lor  Process  Control 
on  small  computers.  MOD ll LA  is  related  to  PASCAL  with  similar 
data  st  nn'tiircs.  It  is  a smaller  language  with  parallel  features. 

Each  module  must  be  specified  with  all  names  used  from  outside  and 
all  used  inside  the  module.  Objects  are  sometimes  •imported1  from 
an  external  environment  into  a module  and  v.v.  Tusk  creation  is 
only  at  the  main  module  level.  Interface  modules  exist  (similar 
to  MORAL  groups)  and  Device  Modules  for  encapsulating  device 
dependent  features.  No  SET  type  and  no  Pointers  of  any  sort. 

Simple  control  structures  with  specific  bracketing  symbol  for  each. 

No  fiOTo.  CASE,  WHILE  etc. 

Synchronization  is  by  signals  will:  primitives  wait,  send  and 
awaited.  MODHLA  i mplement ed  now  on  PDP1J  and  1ms  machine  dependent 
elements  which  would  need  changing  oil  a different  host.  All  i/o 
done  by  a DO  10  operation. 

Language  is  not  now  suitable  for  applications  (no  real  arithmetic, 
file  i/o).  The  solution  for  the  double-buffer  problem  is  in  paper 
351  and  comments  are  invited.  MODULA  is  the  kernel  of  an  algorithmic 
language  with  certain  interesting  features  for  LTPL. 

T5.  Discussion  on  T2  and  T5 

Ilopmann.  Idea  of  splitting  up  systems  is  very  old.  Are  you  aw  tire 
ol  work  of  Lower  at  Newcastle  Univ.  on  Petri  nets?  With  many  Petri 
nets  can  get  interference  between  modules  even  with  correct  interlaces 
to  environment.  MORAL  seems  not  to  counter  this.  Are  you  aware  of 
this? 

Har te . Effect  can  only  be  by  semantic  information  going  down 

channels. 

Ilopmann.  This  can  cause  information  about  internal  structures  to  go 
into  the  network,  so  that  the  network  is  still  tied  to  t. lie  internal 
structure  of  the  channels. 

Wand . How  to  error  messages  work  out  with  2-levels  of  compilation? 

Hart e . We  aim  to  produce  correct  CORAL-66.  This  is  possible  with 

a validated  compiler. 

T i mine  s f e 1 d . Relations  between  queue  and  secured  variables  is  only 

in  the  programmer’s  head,  i.e.  no  automatic  checks. 

liar  I e . This  is  true.  The  synchronization  must  he  tested  bv  bund. 

Tiimne  sf  e I d , Schedul  i nc/task  activation  not  in  language? 

liar  t e . Correct.  Done  by  underlying  MASCOT. 

Pyle. 


V.lia  I is  completion  state  of  MORAL? 


■ R|  PM  ' 
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Hitr  t e . 

Then  Revue 

Pv  l e . 

Hat'll'. 

Pv  I e . 

Unite . 

Wand . 


93^  complete  translator  under  test  at  ItSitE. 
of  language  around  1977. 

Can  you  have  code  inserts? 

The  language  will  not  have  them. 

Vital  is  size  of  kernel? 

Less  than  1000  words. 

MODI  FLA  is  1 03  words. 


Pv 1 o . What  happens  to  unwaited  ST  IMS? 

Ha  rti'.  Queue  has  2 states  0 ST  IMS  - 1 or  more  STIMS. 

Py  1 e . Can  you  tost  it  any  task  waiting  on  queue? 

Harte.  No. 

FI zor . I'm  not  sure  exactly  what  the  LOCK  does. 

Har to , LOCKS  are  compile  time  checks  to  allow  programmer  to 

declare  his  intention  which  can  be  checked  by  the  compiler. 

A field  can  have  multiply  keys  at  declaration  but  only  1 key 
allowed  on  access. 


F.  1 d e r . How  arc  run  time  errors  handled. 

Har  t e , In  Mascot,  whole  network  must  be  defined  at  system 

design  stage.  No  operating  system.  Some  errors  trapped  and 
signalled  on  console. 

E 1 / e r . How  about  i/o? 

Harte . Have  interrupt  control  queue  similar  to  control  queue 

where  a device  interrupt  corresponds  to  a STIM.  Primitive  handler 
must  be  added  to  kernel  for  each  device  added  to  system. 


El zer.  Is  it  not  inconsistent  to  force  user  to  use  assembly 

code  for  input  output  with  high-level  for  other  areas? 


Ha  rue  s . 

Are  waits 

t i me d-ou t ? 

liar  te . 

No,  but  a 

t i me r exists 

so  y ou 

can  do  it  yourself. 

Ha  rue  s . 

What  an. nit 

suh.se  i i pt  e 

rmrs? 

Har 1 e . 

In  MORAL, 

array  bounds 

are  pa 

rt  of  type. 

I'l/ff. 

How  is  tin' 

des  i g it  d i a " 

ran  transformed  into  program  form? 

Harte. 
dnt'umc u t . 

The  (le  s i i'll 
No  <m  t oina  i 

diagram  is 
i r t ran s 1 a 1 1 

I mbii'  in 
on  mis 

1 as  an  early  design 
is  bet weiui  ilia.' rani  and 

pi  im  fibre  si  ru  i 1 1 1 r e s . 


1 

I 

I 

1 


■ 


-155- 


Kl/cr.  Art;  the  interface  modules  of  MODULA  monitors? 

Vand . Not  quite,  more  than  one  process  can  he  in  an 

interlace  module. 

Fv 1 e . MODULA  suffers  from  length  in  solution  to  double 

buttering  as  does  LTPL.  This  is  because  of  amount  of  detail 
in  example. 

Har t o . I will  produce  solution,  in  MORAL. 

E l zer . If  such  a basic  problem  blows  up  into  such  a lot 

of  code  surely  something  is  wrong. 

Ti  mines  f o I d.  1 don't  agree.  Just  because  a problem  sounds 

simple  that  doesn't  mean  that  it  is  simple,  so  a long  solution 
may  not  he  a had  thing. 

Wand . The  MORAL  language  looks  ugly.  Is  this  deliberate? 

Or  is  it  just  me?  Iio\v  big  is  system? 

Hartr . Perhaps  you're  too  fond  of  PASCAL  type  notation. 

Size  of  MORAL  translator  - 5?K.  9000  lines  of  CORAL 

Kernel  - IK  + monitor  + mechanisms  of  systems  elements  file. 

Not  fully  developed  so  I can't  give  size  of  all  elements,  runs 
on  Moduia  1 with  3?K  + discs  with  overlaid  compiler. 


Before  the  individual  group  reports,  the  chairman  mentioned 
that  the  Technical  Advisory  Committee,  consisting  of  government 
sponsored  delegates  appointed  to  advice  EEC  on  L'l  PL  projects, 
has  asked  that  the  subgroups  produce  "snapshot"  state-of-the-art 
reports  on  the  work  of  each  group. 

T6.  Report  of  Algorithmic  Subgroup 
Chalmers:  Our  response  to  TAC  request  is: 

i)  Latest  version  of  our  state  of  the  art  report, 
ii)  Discussion  of  where  we  go. 

The  first  is  . eadily  available  but  we  cannot  say  exactly 
what  the  second  will  consist  of.  Available  state  of  art  report 
is  that  current  June. 

Meeting  attended  by  5 regular  + t new  members.  Dr.tiilhert 
could  not  attend  due  to  pressure  of  work. 

First  topic  was  approval  of  latest  slul<*  of  art  report  which 
was  approver!  wi  th  minor  edi  ts.  This  wi  I I go  to  at  I A-list  mcmhci  s. 
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One  point  we  want  to  refer  to  I/O  group  namely  6.1c 
concern  i iv.'  extensibility:  Extensions  allowin'',  definition  of 
new  nodes/procedurcs  to  use  previously  Inaccessible  features 
of  hardware. 

Second  topic:  detailed  review  o f LTPI.  210  Algorithmic 
Kernel.  Ibis  had  not  been  adequately  discussed.  Prior  to  the 
meeting  a questionnaire  had  been  sent  to  all  members,  and  the 
results  were  collated  and  at  the  meeting  we  tried  to  resolve 
differences.  We  agreed  to  accept  Vi  points,  to  delete  - and 
Vt  are  still  undecided.  In  the  course  of  the  review,  some 
edits  to  219  were  agreed.  Results  will  be  in  next  issue  of 
State  o ! Art  report.  Two  main  reasons  fur  deferrment : 

1)  Could  not  reach  agreement. 

2)  Needed  opinion  ot  I/O  subgroup  - concerning  external 
ivtereru.es  part  of  para  190,  pa  ra  a 0 and  par  t of 
para  bt?0. 

Deferred  points  grouped  into  topics: 

a)  Pointers  and  subscripts. 

b)  Hit  addressing. 

c)  Equivalence. 

d)  Macros  and  text  processing. 

e)  Re-entraney 

f)  boundary  between  compiler  and  rest  of  system. 

Position  papers  have  been  assigned  for  a),b),  c)  and  cl). 
This  will  be  discussed  at  the  next  meeting,  in  line  with  the 
usual  practic.  Also  State  of  Art  report  will  be  updated. 

Still  not  got  a PEARL  expert  on  group.  Mr.  Roger  was  not 
the  re . 

El/er.  Ilow  will  S t a t r ot  Art  report  be  produced?  l)o  you 

plan  another  meeting? 

dial  me > s.  Intend  to  distribute  dune  *7b  State  of  Art  Report 
unless  meet  in;'  possible  in  November. 

El /it;  We  have  most  paid  sessions 

a funded  session.  So  eithei  we  have 
November  or  wail  till  January.  lour 
nexl  nice  ling? 

Cha 1 me  rs . Yes.  It  we  have  meeting  in  November,  we  could  check 
Sep t ember  ropor t . 


ot  any  TC  and  cannot  have 
an  unfunded  meeting  around 
plan  depends  on  date  of 
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F1  / IT. 
Sluto  O f 
\ot  jus l 


We  additionally  need  a critical  analysis  of  tin* 
the  art.  We  need  something  more  suitable  for  the  TAC. 
technical  details. 


Cha  I me  r s . [ thought  they  just  wanted  one  document  listing  all 

the  agreed  point  s . 


F 1 /.c r . We  need  some  idea  of  plan  of  work,  resources  needed  etc. 

Ch;il  me  rs . This  is  set  out  in  the  study  proposal  for  the  Algorithmic 
synthesis.  Could  you  send  a copy  of  the  TAC  minutes  to  subgroup 
cha  i men? 


FI  Mi  net  os  not  detai  led  enough. 

SU  i nne  r . A state  of  the  url  liistor>  is  not  a status  report,  which 
would  contain  an  assessment  of  how  far  we  have  got,  what  must  bo 
done  etc.  I think  that  a standard  s tincture  should  be  decided  for 
each  report. 


dial  me rs.  The  problem  if  J have  to  do  a critical  assessment  is  that 
my  views  may  not  be  the  view  of  the  group  as  a whole. 


Flyer.  This  discussion  must  be  postponed.  Any  technical 

ques ti ons? 

T i mines  f el  d , lias  any  discussion  been  given  to  included  types  like 

DEVICE  etc? 


Clial  t:icrs.  No. 


T7.  Report  of  Tasking  Subgroup 

T inline  sf  cl  d : 7 members  present . Secretary  selected  for  minutes 

to  be  sent  to  other  chairmen,  Mr.  Skinner  of  DEC. 

First  item:  Discussion  on  schedules,  based  on  paper  by  myself. 

Main  proposal  to  identify  schedules  as  items  in  the  languages 
and  to  be  able  to  collect  and  delete  schedules  within  the  language. 
The  proposal  was  generally  agreed.  Mr.  Jones  main  critique  was 
syntax  rather  than  semantics. 

Second:  Paper  on  interruptnbili ty  of  parallel  activities  by 

Uadault  et  al  comparing  LTR  no-interrupt  except  at  selected  point 
approach  with  LTPL  approach  of  inf erruptnbil i t y af  any  point. 

General  opinion  was  LTPE  is  more  general  approach.  LTR  approach 
cannot  be  used  in  LTPL  since  if  is  defined  only  in  terms  of  a 
single  processor  system. 

Th  i r d : Discussion  on  d i s t ti  Ini  f ed  i u l e I I i ••  en  c e . We  fried  to 

formulaic  definition.  Mi  1 1 t i processor  s\  stems  not  ii'j'anlcd  its 
distributed  intelligence  whereas  multi  computer  msIciii  would  he. 
intelligence  implies  general  progi  omabi  I i l y . Hunch  l of  impact 

on  t ask  i iig/l/O . Thought  wo  might  have  restrictions  on  tasks 
running  oil  different  processors  e.u.  onl\  common  ic  a ' i on  b\  messages. 
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Disciission  on  whether  code  or  commands  to  romoto  operating 
systems  should  be  transmissible  as  messages.  Comments  to  be 
brought  to  next  meeting  by  Dr.  Wand  and  myself. 

Decided  that  the  subgroup  chairman  must  produce  state  of  ai't 
report  based  on  LTPL  2'i3  taking  later  development  into  account. 

Then  discussed  role  of  tasking  subgroup  within  CEC  project. 

Task  subgroup  consider  themselves  as  a body  responsible  to  decide 
between  proposals  put  forward  by  Contractors. 

The  following  formulation  was  produced  as  a proposal  for  a 
working  relationship  for  the  first  work  items; 

A minimum  of  - checkpoints  in  contract  to  allow  review. 

Each  review  is  meeting  between  Proj .Manager  Contractors  and 
committee  subgroup  (timed  to  coincide  with  meeting  of  LTPL). 

The  firs  l check  point  will  review  the  following: 

t)  Style  of  definition  to  be  ado]) ted. 

2)  A formalised  scope  definition. 

3)  Difficulties,  contradictions  and  possible  solutions 
detected  so  far. 

A written  report  covering  the  above  should  be  circulated  one 
week  before  the  meeting.  The  checkpoint  might  take  place  two 
months  after  contract  start. 

At  the  second  checkpoint  (3  months  after  1st)  first  draft 
of  whole  definition  should  be  ready.  This  should  be  circulated 
two  weeks  before  the  meeting  and  the  checkpoint  will  comprise 
detailed  review. 

The  group  will  indicate  where  further  material  should  he 
included  or  considered  and  will  approve  the  scope  of  the  definition 
document  and  its  style. 

A discussion  followed  on  what  chance  the  rule  of  the  tasking 
group  would  have  of  being  adopted  or  even  considered  by  CEC. 

Dr.  T i mine sf eld  pointed  out  this  was  a proposal  for  technical 
co-ordination  which  could  be  accepted  or  rejected.  M. Robert  felt 
that  t hose  proposals  were  beyond  the  terms  of  reference  of  the 
Tasking  subgroup  or  even  LTPL . We  need  project,  management  rules 
but  tli  is  should  not  be  decided  by  Tasking  group.  The  chairman 
asked  about  comp  i la  l i on  of  stilt  11s  report. 

T i mmes f cl d . Will  be  produced  in  November  by  myself  and  distributed 

t .)  a I I members . Agreement  will  be  reached  by  correspondences  il  no 
meeting  this  year. 

Bnil iii  1 1 t . Disagree  that  LTit  is  single  processor, 

processor  systems  have  been  sold  using  I lit. 


1 


1 n f at:  t mu  l t 1 - 
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T i mines  f e 1 d . Cannot  have  uni.nterrupt.abi  l i ty  with  many  processors 

ami  one  store. 

D.ulau  1 t . This  is  true  if  only  one  store.  Need  at  least  2 stores. 
M.kronental  can  give  French  view  on  tasking. 

Kronen l al . This  is  still  in  draft  form  and  is  not  the  official 

French  view  as  such.  It  will  he  translated  and  presented  at  this 
grou  p. 

Hadau 1 t . Does  Tasking  group  intend  to  take  the  paper  into  account? 


Tiinmcsfeld.  I can't  comment  since  1 have  not  even  looked  at  it. 

M.  Kroneutal  agreed  io  circulate  the  paper  in  French  to  all 
A-list  members. 

Jones  asked  what  happened  to  Mi'.  Schwoizer’s  proposal  to  gather 
information  on  distributed  intelligence. 

El zcr . I rae  t him  at  TAC.  By  an  error  he  was  not  invited  to  this 

meeting  and  in  any  case  he  has  much  work  due  to  having  changed  jobs. 


TS.  Report  of  i/o  subgroup 

Verrous t : 7 members  in  attendance. 

Presentation  on  new  PEARL  I/O  by  Dr.  Hopmann. 

A deeper  discussion  will  follow  receipt  of  written  report. 

New  discussion  on  process  variables.  Decided  not  to  do 
i/o  this  way.  Then  discussion  on  i/o  study  put  forward  by  planning 
group.  General  approval  expressed.  Need  for  close  relation  with 
contactors  and  standardised  terminology. 

Discussed  criteria  for  contractors.  We  think  that 
suitable  contractors  could  be  found. 

Regarding  TAC  request.  Paper  LTPL  505  will  be  expanding 
to  fulfill  request. 

At  next  meeting  Dr.  Wild  will  present  CORAL  i/o,  also 
discussion  of  IPL  I/O  and  also  we  will  start  on  standard  terminology 
and  TAC  snapshot.  Now  also  we  plan  a short  joint  session  with 
Algorithmic  Group. 

Main  problem  we  bring  to  plenary  is  need  of  terminology 
standard  if  many  contracts  will  be  placed.  Intend  to  use  IFlP/lSO 
terms,  not  invent  r ew  ones. 
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T l /c  r . I assume  that  you  are  assumin'’,  another  men  tin,*'  this  year? 

Mr.  Hopmann  Knows  of  work  on  terminology  standards. 

Hopmann . ISO  subgroup  working  on  standard  terms  for  inpul  output  . 
Clin  1 nu  • rs  . Will  results  he  available  in  time? 

Hopmaun . German  standard  exists  for  Operatin''  Systems  and  drat  I - 
standard  fot  concm  rem  \ ele.  The  work  in1!,  ol  the  nation.il  standards 
organisation  is  part  ol  (he  rev  i s i on  of  the  (So  data  process  i ng 
g 1 ossa  i > . 

Ve  iti  si  •;  t . Wo  need  a set  of  Fair.  I i sh  terms.  I think  we  must  use 
It  IP  do'  ament  and  an\  ether  useful  hooks. 


A discussion  followed  on  which  lerminnlogx  should  he  used  and 
how  we  ran  avoid  a divergence  between  l TIM  terns  and  some  tut ure 
standard  which  might  later  he  imposed  upon  us.  No  firm  decision 
came  out  but  the  chairman  requested  oil  subgroup  chairmen  to 
consider  problem. 


T1).  Itcport  of  Evaluation  Criteria  Snh"ronp 
l.e \ v ; r)  members  + Mr.  Socol  of  U.S.  Army. 

Not  much  work  done  up  to  now.  Concluded  evaluation  criteria 
strongly  related  to  design  criteria  which  in  turn  arc  strongly  relating 
to  functional  requirements.  So  wo  need  functional  requirements. 

A number  ol  lists  exist  and  it  is  a lot  of  work  to  process  all  the 
papers  on  this  topic.  Til  i s has  been  proposed  as  a project  within 
CKC.  Cannot  be  done  internally.  Work  detailed  ia  Project  Proposal 
Doc  u men t . 

Regarding  snapshot  report.  Very  d i Ifienlt  now,  so  we  may  try 
doing  the  work  of  the  contractin'  in  a very  sketchy  way  and  draw  up  a 
small  precis,  and  add  a section  on  the  plan  oi  work  in  outline. 

Must  ask  other  subgroups  to  input  the  design  criteria  they  are 
using.  Also  discussed  how  we  could  interact  with  l\E(  Project. 

General  rules  agreed.  1 would  sax  Tasking  Group  ideas  in  this  are 
too  detailed  and  unrealistic. 

Our  meetings  are  every  1 months  so  we  cannot  follow  a contract 
closelx.  Dny-lo-dnx  problems  mns I be  done  In  a project  leader. 

We  mns  I g i V"  advne  i o project  leaders  am)  give  alter—  the  — la<t 
reports  and  opinions  on  work  done  and  pa  pe  i s pi  oil  lie  ed . 

Had  general  discussions  on  I ea  i Mali  i I i t v , ease  ol  use  etc. 

Also  decided  that  one  wav  to  jud-e  lum  tional  requirement  is 
h\  sample  problems,  e.g.  double  buffer  problem.  We  would  like  to 
receive  sample  problems  w i l 1 1 oi  w i l 1 1 oi  1 1 sola  Minis. 
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Elzer.  Good  iik* a for  other  groups  to  make  explicit  their 

ties  i "it  criteria.  Does  the  group  plan  to  start  uheru  the  previous 

one  left  off? 


Levy . Don'' t think  there  can  he  real  coni  i unify.  Two  types 

of  activity  up  to  now; 

1)  Structuring  of  work.  This  structure  has  now  been 
re  j ec  toil . 

2)  Discussion  of  various  topics  which  will  carry  through 
into  the  new  group. 

I'lzer,  ’.Chut  about  go  inn  through  papers  tot  t u tic  t tonal  mm  i remer  i s 

other  than  "lirecu  Sheets’1.  Other  papers  exist  iron  later  meeting. 

Levy . A contractor  would  be  needed  to  analyse  the  existin'  data. 

2-9  month  effort  is  needed.  I can  only  list  the  relevant  papers. 

The  state-ot-art  report  will  he  written  by  myself,  circulated  by 
post  for  correspondence  and  then  redrafted  to  take  account  of 
cri ticisms . 


Pyle . Evaluation  criteria  are  not  just  related  to  technical 

usefulness.  Feasibility  and  acceptability  must  be  considered. 

Levy . Yes,  we  agree  that  these  criteria  must  he  taken  into 

account . 


Regarding  terminology,  I suggest  that  LTPL  glossary 
which  has  been  produced  by  ISA  be  used. 

E 1 y,c r . Now  I think  we  must  close  session.  It  seems  that 

requirements  for  status  reports  are  not  clear.  1 suggest  a short 
discussion  with  M.  Malagurdis  and  the  subgroup  chairmen. 


Meeting  resumed  at  9.00  a. lit.  171b  September  1970 
TIP.  Discussion  of  Tinman  comments 

Elzer.  Collected  comment  under  LTPL-350  and  again  with  corrections 

under  350a  and  again  under  350b.  All  members  have  this  and  it  is 
also  in  draft  minutes.  Pr.Pyle  took  over  as  chairman  for  this  item. 
He  reviewed  the  papers  relevant  to  this  for  members  to  cheek  that 
they  all  have  been  sent.  A request  for  further  comments  was  issued 
and  Mr.  J.  Darnes  agreed  to  supply-  one. 

Chalmers.  Attempt  was  made  to  get  barren  leper  to  give  information 
aliou  t comments  made  at  Zuriih  without  any  suet  ess. 

Neavc . Closing  date  for  i eminent  s was  lime.  What  will  happen 

to  comments? 
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jjjOg  OOPY  FURUl^HbD  TO  UDC  - 

WpiuiMr.  Next  stop  is  Cornell  meeting  at  start  of  October. 
Comments  produced  quickly  could  still  be  processed. 

Pvlo . Only  input  to  Tinman  if  communicated  in  time,  but 

in  any  ease  they  are  input  to  LTPL. 

n.-tdati  1 t . Respecting  criteria  of  feasibility  anil  acceptability, 
l think  Tinman  will  be  too  largo  and  complex  for  LTPL.  We  inns  t 
simpl L fy . 
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Minutes  of  Business  Meeting 


THIS  PAGE  IS  BEST  QUALITY  PRACTICABLE 
IROil  COPY  FURNISHED  TO  DDC 

17.9.76  ''  ' 


Bl.  Approval  of  Minn t os 


It  was  agreed  that  the  Collected  Subgroup  discussion  in 
minutes  will  bu  replaced  by  a reference  to  paper  350b.  Areas 
in  later  discussions  where  clarification  was  unsuccessfully 
sought  from  Fisher  will  be  numbered  to  enable  later  inserts. 


M.  Robert  suggested  that  the  other  part  of  the  Tinman 
discussion  be  moved  from  the  minutes  into  paper  350.  Also 
Mr.  Barnes*  comments  will  be  ready  mid-October  for  incorporation 
into  350. 


Problem  of  .January  and  Zurich  minutes  was  raised  again. 
Still  not  distributed  in  final  form.  Chairman  agreed  to 
contact  I)r.  Dietrich  who  was  indisposed  and  unable  to  attend 
the  meeting. 


Robert . Last  meeting  decided  all  authors  should  distribute 
own  papers.  Need  to  spread  load,  as  regards  printing  and 
distribution. 


Pr.  Pyle  volunteered  to  arrange  distribution  of  32nd  meeting 
but  a problem  of  collection  of  information  exists.  Written 
comments  on  32inl  meeting  were  given  to  Mr.  Chalmers  who  accepted 
the  task  of  printing  and  distribution. 

Wegner.  All  missing  papers  were  mailed  to  Dr.  Dietrich  at  his 
private  address  2 months  ago. 

Elzer.  This  means  material  all  exists. 


Additional  item:  Mailing  list  check.  Some  inaccuracies  had 
come  to  light. 


B2.  Report  of  planning  group 

Elzer.  On  15th  September  the  TAG  (Technical  Advisory  Committee) 

met  for  first  time.  This  was  formed  by  suggestion  of  Mr.  Layton 
to  advise  the  EEC  on  LTPL  work.  The  committee  consists  of 
government  appointed  delegates  and  advisory  experts.  The  LTPL 
chairman  attended  the  meeting,  which  was  chaired  by  Layton. 

Three  items  on  agenda: 

1.  Charter  of  TAG  and  relations  to  LTPL-E. 

2.  Comments  on  technical  papers  prepared  by  EEC 
and  LTPL  committee. 


3. 


Data  Exchange  with  DOD 


f 
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, A Mr.  Soool  of  L'.S.  Army  attended  this,  thinking  that 

the  LTPL  plenary  was  un  that  day. 

Regarding  data  exchange,  Mr.  Socol  saw  no  difficulty  though 
a formal  system  would  take  time. 

In  Planning  group  discussion, dissatisfaction  was  expressed 
that  the  L'.S.  do  not  reply  to  requests  for  information,  so  that 
communication  is  "one  way".  This  was  generally  felt.  Mr.  Socol 
thought  this  might  he  due  to  lack  of  co-ordination  rather-  than 
lack  of  willingness.  Mr.  Socol  has  been  asked  to  do  liaison  role. 
He  noted  the  dissatisfaction  with  the  communication  from  U.S.  to 
LTPL. 

Further  problem  with  Cornell  Lniv.  workshop.  Names  given  to 
Dr.  Fisher.  A letter  was  given  to  LTPL  Chairman  as  tentative 
invitation.  Imitation  received  on  sth  September  to  LTPL  Chairman 
hut  no L to  Purdue  Fur ope.  This  situation  needs  to  be  regularised. 

Mai aga id 1 s . More  needs  to  be  said  about  method  of  selection  of 

LTPL  members.  This  lias  been  done  without  reference  to  LTPL 
committee.  This  effectively  inhibits  co-operation. 

Sk  inner.  Viha  t.  is  purpose  of  co-operation? 

Malargai dis , At  least  exchange  of  information  which  is  not  being 
done . 

Mr.  Hart.c  pointed  out  that  this  discussion  belonged  under  BT. 

Back  to  TAG  meeting. 

El /or. 


1.  Self-understanding  of  TAG. 

TAG  want  broader  scope  than  LTPL  with  no  upper  limit  on 
breadth  except  for  not  impinging  on  CREST  Informatics  Committee. 

M.  Malagardis  explained  that  CREST  is  a CFX  body  set  up  to  look 
at  research  projects.  Currently  has  done  research  on  networks 
leading  to  formation  of  FIX.  Subgroup  on  Informatics  has  list 
of  topics  to  be  investigated  and  proposed,  including  Real  Time 
Languages.  J.  Noyes  suggested  joint  CREST/TAC  meeting  to  sort 
out  respective  spheres  of  interest. 

FI  />'!'. 


Meeting  discussed  relation  of  TAG,  LIPL,  Project  Leader  etc. 
TAG  was  to  ite  advisory  body  to  Project  Leader  with  official 
status  with  right  of  guidance  and  control  of  Project  and  Project 
Manager.  LTPL  is  advisory  group  used  at  request  of  Project 
Manager  for  technical  advice. 

On  Data  Exchange, agreed  that  LTPL  should  have  a say  in  form 
o t exchange. 
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2.  Discussion  of  papers. 

Discussion  on  Project  Plan  ami  the  planning  group  document 
on  initial  Projects.  Some  discussion  on  question  of  degree  of 
correlation  of  projects. 

M.  Malagardis  took  the  chair  at  the  TAC  meeting  for  the 
discussion  of  the  paper  on  Initial  Project  Proposals.  It  was 
pointed  out  that  this  represented  some  divergence  from  the 
project  plan.  The  committee  were  told  in  reply  to  this  that 
this  divergence  was  not  great  ami  was  within  spirit  of  the 
project  plant. 

The  Initial  Proposals  has  a horizontal  and  vertical  slnictme. 
Horizontally  they  include  studies  for  language  skeletons  which  are 
overview  studies  of  the  language  as  a whole  which  arc  needed  to 
ensure  collusiveness  between  studies  in  different  areas  of  the 
language . 

U skeleton  studies  proposed: 

1.  Language  comparison  synthesis. 

2.  Skeleton  in  spirit  of  LTPL-219. 

3.  Skeleton  in  spirit  of  Simula  Pascal. 

A.  Study  in  very-high-level  languages  translatable 
into  other  high-level  languages.  Somewhat  like 
MORAL. 

At  vertical  level  are  the  elements  of  work  of  each  of  the 
subgroups,  for  which  studies  have  been  proposed. 

The  Evaluation  Criteria  work  is  viewed  separately  and  it 
is  desired  to  produce  a requirements  document  and  a study  is 
proposed  for  this. 

Lastly,  it  is  suggested  that  contracts  be  given  to  collect 
sufficient  sample  problems  which  will  enable  the  language  features 
to  be  evaluated.  These  problems  should  not  be  submitted  by  the 
language  designers.  They  must  be  done  independently  to  ensure 
they  are  not  just  biased  to  any  language. 

There  was  criticism  of  this  document.  A minor  criticism 
was  that  only  LTPL  documents  were  referred  in  paper  31,». 

A major  criticism  was  levelled  at  the  suggestion  that 
contractors  should  be  chosen  amongst  those  familiar  with  the 
ongoing  work  ol  LTPL.  Some  members  felt  this  was  setting  up 
a closed  shop.  Also  criticism  that,  effort  estimate  not  high 
enough  to  lie  realistic.  This  was  answered  by  saying  that  this 
was  oulv  introductory  work,  not  the  whole  thing. 


A surprising  opinion  was  expressed  that.  LTPL  was  too 
academic  biased  and  a complaint  was  made  on  Lack  of  readily 
ass  i i'll  1 a tab  1 e in  to  rma  t ion. 


TAC  requested  a short  report  from  each  subgroup  detailing 
ach  i e v.’fttn  t so  tar,  proh  ! ems , hopes,  tears  etc.  Funding  depends 
on  these.  TAC  next  meeting  on  2Ttid  October  and  they  want,  to 
see  LTPL  Self  Representation  document  as  soon  as  possible. 

Meeting  ol  higher  officials  group  on  2'ith  September  which 
will  again  discuss  the  monetary  framework.  It  is  hoped  it  will 
go  before  Council  of  Ministers  at  end  of  year. 


1 


1’He  question  of'  separation  of  LTPL  from  its  (.I'unecfed  projects 
was  raised  (see  33rd  minutes).  M.  Robert  pointed  out  this  comes 
under  B3. 

Robert . Planning  group  has  had  1"  hoars  of  meetings  counting 
the  special  meetings.  This  special  meeting  has  not  been  till  In 
reported  and  this  is  a general  problem.  For  instance  planning 
group  minutes  are  produced  but  not  distributed. 

Elzer.  A brief  report  then  can  be  given.  At  33rd  meeting 

i t was  agreed  that  on  9tli-lllh  August  a special  meeting  of  planning 
group  should  take  place  to  set  out  proposals  for  initial  proposals. 
This  took  place  and  paper  has  been  given  to  TAC  and  to  Planning 
Group  members. 

Robert.  Even  if  the  report  "13  is  distributed,  any  discussion 
Tti  the  plenary  will  he  too  late. 

Elzer.  This  will  be  discussed  Litter.  Planning  group  agreed 

we  must  speed  up  self  representation  of  LTPL.  IF1P  group  3.3, 
it  was  discovered,  is  working  in  the  same  field  as  LI  PL  anil  this 
was  being  investigated. 

Mr.  Hopmann  reported  on  PLIP.  First  meeting  at  end  of  this  year 
in  Washington  (November).  Three  papers  already  input  to  FLIP. 

A proposal  for  Process  FORTRAN  wil 1 he  put  forward  by  ANSI.  Also 
PLl  standards  group  for  Process  Control  luts  been  revived. 

Then  some  discussion  on  importance  ot  Tinman,  problems  ol 
communication  etc.  This  was  the  last  item. 

To  return  to  main  issue  o I the  proposals  lor  initial 
contracts.  It  was  a"  reed  that  planning  -roup  would  discuss  t It  t s . 
These  will  he  distributed  to  .til  A-g  roup  members. 

Robert.  Must  point  out  that  those  ate  drafts  not  lor  TAC 

mo*,  t j 1 1",  (which  we  didn’t  know  about)  but  for  Soptemhei  meeting  as 

extension  of  Project  Plan. 


Ll 
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Bow ke r . I was  hoping  that  some  discussion  would  have  taken 

place  on  these  proposals  at  this  meeting  anil  and  the  documents 
would  already  have  been  distributed.  Now  it  appears  that  no 
discussion  can  take  place  before  January  (probably)  which  is 
too  late  to  be  meaningful. 


Elzer. 


I intend  to  distribute  it  so  it  can  be  discussed  at 


next  plenary.  The  situation  is  not  so  bad  as  has  been  suggested. 

1.  TAC  group  will  modify  certain  aspects. 

2.  I ask  lor  written  comments.  None  received  so  far. 

Necessary  then  to  extend  t li  i s plan. 

Bow ko r . What  is  procedure  for  approval? 

El/er,  Normally  will  lie  approved  by  full  meeting.  Problem  is 

fluid  situation.  It  is  difficult  to  act  agreement. 


Rober  t . 


Amendments  to  proposal  are  of  2 types: 


1.  Amendments  to  existing  proposals. 

2.  Additions  to  proposals. 

No  pedantic  comments  should  be  made. 

Need  for  expansion  of  all  modules  in  first  2 years. 
Extensions  are  the  more  important. 

Bad an  1 t . 2 problems: 

1.  Approval  of  proposals. 

2.  CEC  timescales. 

I suggest  a meeting  in  December  to  clear  this  up. 


The  chairman  then  suggested  that  item  B6  be  brought  in, 
in  view  of  this. 

lib.  Next  meeting 

E 1 ze r . No  real  possibility  of  another  paid  meeting. 

Do  we  agree  to  have  a meeting  in  beginning  December? 

Robert..  I suggest  we  have  2 more  meetings  before  Zurich. 

Late  November/early  December  and  another  in  January/February  1977. 

M.Malagaid is  pointed  out,  for  information,  that  the  next  full 
Purdue  Europe  meeting  may  be  at  ispra  in  Italy. 


Alter  some  discussion  it  was  agreed  to  have  an  unsponsored 
meet  im r on  7ih  December  1076  9.60  a. in.  to  Sth  December  1*176 
12  noon  al  1RIA,  Paris  with  planning  group  at  180011  on  6th  December. 
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P~> . Anproxal  of  Self  ltepresfMi  I a t i on 

hi  /it.  1 had  hoped  that  self-representation  would  cause  no 

problems.  Paper  .V*  1 A has  been  written  and  amended  more  than 
once.  It  appears  that  Pr.  Pyle  still  feels  one  alteration. 

Pv 1 e . I don't  want  to  hold  hack  circulation  due  to  my 

comment,  and  ] think  it  is  too  late  to  start  discussion  now. 

Vaml . The  comment  came  from  2 U„S.  visitors  query  in" 

who  tlier  PI.  I style  was  necessary.  Their  opinion  was  that  PM 
style  in  irh  i e'en  hindcj  the  acceptance  of  LTPI.. 

P\  1 e . Therefore  the  sentence:  "1  I PL  will  be  a companion 

language  to  PL.l  in  the  same  way  that  CORAL  is  a companion 
language  to  Algol -hO"  might  nol  help  t lie  acceptance  of  LiPL. 
Perhaps  we  should  leave  it  in  and  wait  l'or  comment. 

Wand . I suggest  the  sent  once  he  struck. 


9 


A vote  was  iakea  and  the  motion  that  "the  sentence  be  struck" 
was  carried  by  IT  for  to  It  against  with  h abstentions. 

Second  motion  proposed  was  that  "That  in  view  of  the  necessity 
of  presenting  i.TPL  to  TAC,  the  paper  be  published  before  1st 
week  of  October  with  the  untended  just  passed". 

Passed  uuun imously. 

The  chairman  expressed  the  hope  that  this  vote  does  not 
imply  any  total  rejection  of  PL1  or  any  relation  between  PL1. 

Some  discussion  followed  on  what  implications  might  be 
drawn  from  this  vote,  and  Pr.  Pyle  suggested  that  an  item 
should  go  onto  the  Agenda  of  the  next  meeting  in  the  Technical 
Session  so  that  the  attitude  ol  the  Croup  towards  PL1  could  be 
clarified.  Mr.  Elzer  supported  this  suggestion. 


It*.  Discuss  ion  on  status  of  EEC  projects 

Jumps.  Will  precise  terms  of  reference  of  TAC  be  published 

to  mi •iiiiiers? 

Elzer.  The  terms  of  reference  are  still  not  clear.  When 

information  is  available,  it  will  be  sent, 

Ti  mines  I el  d.  'I  he  (postion  of  the  relationship  between  1 I'PL 

"roup  and  CEC  and  coni rar tors  was  postponed  to  this  meeting. 


F 1 zc r . I remember 

CPC  on  ibis  matter, 
interact  ten  proposed. 
Subgroup  thought  that 


there  were  two  opinions  on  how  to  influence 
One  was  tasking  group  wi  ill  firm  detailed 
On  the  other  hand,  the  L valuation  Criteria 
i lose  liaison  would  be  impracticable. 


i 
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Tirunesfeld.  Different  views  may  be  due  to  different  work 

items.  Evaluation  project  is  primarily  gathering  information 
whereas  tasking  group  implies  many  technical  decisions  and  so 
we  need  closer  liaison. 

Elzer.  Contractors  welcome  additional  complications  due  to 
greater  possibilities  of  slip-generation.  I think  these  complex 
interactions  will  complicate  things  too  much. 

Timmes fold . Alternative  is  that  result  of  contract  will  not 

be  su i table . 

Skinner.  Could  this  not  go  onto  Agenda  at  next  meeting. 

Not  practical  to  discuss  it  now. 


D;i . Hoi  a ti  on  to  ITS — !)0! » Project 


Hobo  r t . Not  only  problem  with  DOI)  but  LiPI.-A  also  do 

not  give  information. 


El zer . LTPL-A  internal  organisation  problems  could 

account  for  their  silence. 


Robert.  LTPL-A  meetings  are  going  on  and  reviving  idea 

of  PL  l for  Process  Control.  Not  enough  of  this  is  communicated. 


Elzer,  LTPL-A  send  minutes  of  meeting  to  myself. 

Robert . But  minutes  were  agreed  to  be  sent  to  all  LTPL 

A-List  members.  Certain  people,  myself  included,  were  appointed 
as  distribution  points,  but  in  3 years  1 received  nothing. 

Elzer.  Main  problem  is  relation  to  DOD.  Problem  is  lack 

ol  communication  from  DOD  and  that  Data  Exchange  is  only  one-way. 


B7.  Preparation  for  Purdue  Workshop 

Elzer.  Main  topic  is  production  of  combined  Tinman  comments,  of 
all  LTPL-C . So  all  possible  comments  must  be  sent  in  detail. 

Also  I want  to  investigate  what  is  going  on  with  PL1 
and  talk  to  DOD. 

Py 1 p . My  comments  are  personal  and  may  he  presented 

but  not  as  in  any  way  representative  either  as  LTPL-E  or  algorithmic 

subgroup . 

Elzer.  I will  assume  that  all  comments  should  i>e  viewed 

as  personal . 
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Rohe r t . 


Only  proper  point  of  contact  with  U„S«  is  via  LTPL-C, 

Americans  work  through  ISA  or  AN'Sl  and  seek  to  impose  on  others, 
We  must,  have  discussion  at  international  level,  votes  are  no 
use  if  we  are  not  involved  in  discussion.  We  need  to  pul 
forward  rules  of  good  conduct. 

F.l  / c r . Could  M.  Ma  lag  aril  is  write 

mi  t dXfficul ty  oi  working  with  U.S.? 


to  Pr.  Williams  pointing 


It  was  pointed  out  that  the  U.S,  habit  ol'  slior  l-cu  t tim 
L'l'PL  m any  important  development  is  rather  typical  of  human 
nature  which  was  somewhat  beyond  the  scope  of  LTPL.  Little,  it 
was  thought,  could  be  done  about  it,  and  M.  Mai agat d is  felt  it 
was  not  appropriate  to  enter  into  i.ontrcversy  with  1 „S.  or 
Pr.  Williams  on  this  mutter. 


B8 . Any  Other  Business 


No  items  required  discussion. 
Meeting  closed  at  1230. 
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MINUTF.S  OF  T11E  36111  MEETING  OF  LTPI.-E 
31ST  JANUARY  TO  2ND  FEBRUARY  1977 


List  of  participants: 


P.  Elzer 
R.A.  Bowker 
E . Wegner 
A.F.  Chalmers 
W.E.  Quillin 
J.D.  Ichbiah 
H.D.  Williams 
J.W.  Roberts 

J. G.P.  Barnes 
A.  Skinner 

R.  De  Morgan 
T.  Golborn 
G.  Cohen 
T.J.  Froggatt 
N.V.  Jones 
M.E.  Helfert 

M.  Inderst 

K. H.  Timmesfeld 

S.  Savoysky 
J.  Robert 
G.  Verroust 
J.  Teller 
R.F.  Maddock 

N. E.  Malagardis 
M.  Kronental 

W.  Teasdale 
R.  Gilbert 
P.  Deschizeaux 
D.C.  Rummler 

O.  Dietrich 


Univ.  of  Erlangen 
Ferranti  Ltd. 

GMD 

GEC 

Plessey 

CII  Honeywell  Bull 
MBP  GmbH 
MBP/EWW  GmbH 
ICI 
DEC 

Dataskil 

SDL 

CERCI 

Univ.  of  York 
HPA 

Univ.  of  Stuttgart 
ES  GmbH 
IDAS  GmbH 
LCPC 

CAP-SOGETI 
Univ.  of  Paris 
Siemens  AG 
IBM 

IRIA/CTI 

IRIA/CTI 

AERE  Harwell 

AERE  Harwell 

Univ.  of  Grenoble 

Office  of  Naval  Research  (US) 

CEC. 


Chairman 

Secretary 
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Plon.try  Mooting  Minutes  Iht.h  I.TPL  Meeting 

1st  I'ohrtiary  I *>77 


Meet  Lug  open  at  l-'iOO  hrs.  with  welcome  by  Chairman. 


Approval  of  Anemia 

l/n tor  tuna  tel v,  some  members  had  not  received  agenda 
although  it  was  posted  19. 1.77.  It  was  noted  that  for 
UK  at  least,  Id  days  postal  delay  is  usual. 

No  alterations  to  agenda  were  made. 

Introduction  of  new  members 


T. 

Froggatt 

Univ.ol  York.  Work  in 
design  at  York.  Task  in 

real-time  language 
g Subg. 

W. 

Teasdale 

AERE  HARWE.LL  . Working 

systems  and  networks. 

on  distributed 

G. 

Cohen 

CERCl  paris.  Languages 

& Compilers. 

T. 

Golborn 

SDL.  interest  in  Coral/Pascal . 

Apologies  for 

Absence 

Apologies  for  absence  were  received  from: 

I.C.  Pyle 

I.  Wand 

J . Levy 

H.  Harte 

Attendance  for  Christian  Rovsing,  the  Punish  firm,  will 
in  future  be  by  Mr.  Steen  Hansen,  Mr.  iividi  can  no  longer 
come . 

HSRE  England  can  no  longer  attend,  so  Mr.  Sieve  will 
not  be  coming.  This  is  due  to  pressure  of  work  and  the 
unavailability  of  experts  with  the  right,  background. 


Report  of  Algorithmic  Group 
Cha  I me  rs 

Attended  by  Oof  the  regular  members.  We  also  had  a joint 
meeting  with  I/O.  Started  with  minutes  approval  and  actions  review 

Main  item  was.  those  algorithmic  kernel  features  deferred  due 
to  disagreement  from  previous  meeting,  viz: 
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1.  Pointers  and  references 

2.  Array  Dijnepsfpns 

3.  Common  access  and  equivalence 

*4.  Source  - text  processing 

5.  Bit  addressing  and  packed  data. 

As  regards  pointers  and  reference  it  was  agreed: 

Algorithmic  kernel  has  qualified  pointers  only. 

Maybe  full  language  will  contain  unqualified  if  needed  - for 
system  programming.  There  shall  he  variable  selectors  with 
either  explicit  tag  assignment  (efficient,  unsafe)  or  implicit 
through  assignment  of  aggregate  assignment.  This  alternative 
is  still  open,  with  a paper  to  be  done  by  M.Ichbiah.  Some 
safety  questions  still  open. 


As  regards  bit  addressing  and  packed  data: 

Handling  of  packed  data  is  done  by  declarative  means  not 
by  statements.  Packed  data  structures  should  he  declarable 
as  well  as  sets  and/or  arrays  of  (possibly  single-bit)  0ooieans„ 
State-of-Art  report  will  be  modified  to  excimle  single  bit 
variables  and  type  bitstring. 

As  regards  discussion  with  l/O  group,  we  discussed  only 
the  question  of  language  extensions.  The  Algorithmic  group 
proposed: 

1.  Algorithmic  kernel  must  be  powerful  enough  to  define 

l/O  as  a natural  extension  without  any  kernel  extensions. 

2.  Standard  I/O  will  be  defined  as  part  of.  the  LTPL  definition. 

3.  I/O  in  the  kernel  will  be  by  procedures. 

The  full  language  may  contain  higher  level  constructs 
(e.g.  Formats). 

R.  Gilbert  will  update  State-of-Art.  Report. 

At.  ISPRA  we  will  discuu.sy  3 on  Is  land  i nr  points,  plus 
M.  Deschizeaux  paper  on  synchronization  plus  Papers  by 
I.  Pyle  on  State-of-Art  Report,  arru>  dimensions  amt  static 
data  sharing. 
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Kronen  tal 

Cll  Algorithmic  Paper  available  soon  in  English. 

This  needs  a number. 

Number  LTPL-E/373  was  assigned. 

El  7,0  r 

Kernel  l/o  by  procedures  is  not  high-lpvel  enough. 

This  needs  more  discussion.  A language  contains  many  types 
oi  data  and  devices,  all  of  which  have  peculiar  properties 
so  that  not  all  data  can  go  to  all  devices.  This  needs 
checking  which  cannot  be  done  by  procedures. 

Ti mmes f e 1 d 

This  implies  unions,  will  these  be  in  LTPL? 

Ichh iah 

First,  we  have  not  reached  decision  on  unions.  Second,  I 

SIMULA  does  not  support  unions  but  has  good  procedural  I/O. 

I think  we  cannot  discuss  this  now  and  1 think  we  need  papers 
setting  out  objections. 

E Lie r 

Limiting  plenary  discussion  will  cut  out  people’s  ubility 
to  make  objections.  This  is  too  important  to  limit  discussion. 

llowko  r 

Does  l/o  group  really  agree  to  subroutines  only? 

Verrous t 

This  question  will  be  covered  by  my  report. 

El  zer 

I do  not  want  this  decision  to  be  taken  by  one  group. 
lehbiab 

Since  Elzer  and  Timmesi'eld  clearly  have  important  points 
on  this  problem,  1 think  they  should  prepare  u paper. 

■ 

E l/er 

Certainly  there  are  clear  problems  with  only  having 
procedures  and  it  a procedural  .interlace  is  chosen,  the  reasons 
lor  this  must  be  clearly  stated  wllo  arguments  for  and  against. 

Al  so. question  of  extensibility  is  stilt  outstanding. 

T i mines  lei  <1 

In  order  to  pass  needed  information  oy  a parameter,  this 
parameter  must  have  various  possible  aitribut.es,  this  implies 
unions.  Do  we  want  these  for  all  ol  LTPL? 

Unhcr Is 

In  Algol-(i.s  i lie  parameter  me  chant  ms  lies  been  shown  to  he 
inadequate,  without  special  types  for  procedures  only. 
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Vlegne  r 

Maybe  unions  are  not  needed,  but  other  features  are  which 
are  needed  for  I/O  only.  For  example  : multiple  procedure 
entry  points,  local  data  preserved  from  one  call  to  another. 

Kobe  r t 

It  is  advantageous  for  the  compiler  lo  generate  code  for 
l/O  because  of  lower  chance  of  error  in  sequence.  This  does 
argue  for^higher  level  const  mot.  I think  that  either  high- 
level  only  or  low  level  only  is  wrong.  Why  not  both  types 
which  both  have  applications? 


To  ller 

We  need  some  mechanism  for  extensibility  for  new  devices. 

So  we  need  a flexible  system.  An  example  is  a laser-printer 
which  can,  Cor  instance,  change  the  character  font. 

I ehh iah 

If  a new  device  comes  along  which  does  not  fi  t the 
statements  available  then  the  compiler  must  be  modified. 

It  is  more  preferable  only  to  have  to  modify  library. 

K Lze  r 

This  is  true  from  vendor's  point  of  view  but.  not,  from 
users. 

T i mines  to  L d 

Generally,  of  course,  we  should  avoid  change  to  compiler. 

Hut  in  any  case,  a new  device  will  need  a tot  ol"  programming 
effort  of  some  sort,  luul  a compiler  change  may  not  be  so  much 
larger  in  terms  of  effort  to  justify  excluding  l/o  statements. 

Kobe r t 

Devices  may  be,  in  fact,  a complete  computer  system  with 
many  possibilities  and  p*  rhups  communication  via  message  passing. 
In  this  case  we  can  use  existing  devices  (CALL,  THAXSMIT)  bu  t.  in 
this  case  there  is  no  possibility  to  syntax  clink.  This  checking 
is  not  usually  in  the  Operating  System,  so  that  (booking  eiui  only 
be  with  higher-level  I/O. 


\ 


Deport  of  1/(1  Subgroup 
Vo  r rons t 

First  we  had  discussion  to  prepare  for  joint  meeting  with 
Algorithmic  Group. 

1.  Problems  and  nature  of  language  extensibility  features. 

- • Uses  of  language  extensibility  in  l/o.  Long  discussion 
on  graphic  l/o  including  problems  of  remote  graphic 
computing. 

1.  Use  and  problems  of  a format  feature  in  a language. 
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Statements  agreed  at  the  meeting  were: 

1.  Kernel  must  be  able  to  define  all  I/C  facilities 
without  requiring  additional  features. 

2.  Together  with  language  definition,  standard  T/0 
facilities  in  terms  of  I.TrL  will  be  published. 

3.  Later,  the  facilities  may  be  extended  to  higher 
level  facilities  (e.g.  formatting, ) . 

Provisional  agreement  on  these  three  sentences  still  need 
further  agreement  on: 

- Data  types  in  Kernel 

- Iiist  processing 

- Level  of  LTPL,  i.e.  distance  between  I.TPL  and 
machine  interface. 

Next,  we  started  building  a set  of  LTPl.  I/O  features 
starting  from  language  comparison  manual.  Then  we  had  discussion 
on  TC8  relations.  We  need: 

- to  define  features  needed  to  call  an  operating 
system.  Real-time. 

- to  settle  interface  between  compiler  and  operating 
sys  ten; . 

Then  discussion  on  terminology.  This  was  in  response  to 
paper  by  T.  Pyle.  We  are  not  prepared  to  become  a terminology 
subgroup  but  obviously  wo  will  clarify  terms  used  in  our  work. 

Finally  discussed  I.Tl'l.-K/3bl  , a paper  by  LTFL-A,  which 
contains  a section  on  I/O. 

F.ly.er 

I can  see  a problem  with  so  many  Joint  meetings.  What 
about  further  meeting  with  Algorithmic  Subgroup? 

Chalmers 

Impossible  at  ISPRA,  due  to  shortage  of  session  time. 

Riser 

Can  I/O  group  prepare  list  of  primitives  and  give  it  to 
Algorithmic  Subgroup  so  they  can  describe  them  according  t.o 
their  proposals?  How  far  has  this  work  gone?  When  could  such 
a paper  appear? 

Verroust 

Maybe  June  or  September.  Must  be  discussed  in  June. 
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El  zer 

Is  l/O  group  synthesizing  i/o  from  the  Language  Comparison? 

Can  l/O  group  produce  a unified  position  paper  on  I/O? 

Verrous  t 

Yes  to  both  questions.  But  Language  Comparison  document 
is  partly  out  of  date  and  other  sources  are  used. 

T inunesfeld 

It  has  been  asked  for  groups  to  hand  over  evaluation  criteria. 
Are  other  groups  doing  this? 

Chalmers 

We  have  a feeling  that  Eval.Crit.  should  come  from  outside. 
Think  that  Tinman  should  be  source. 

Timmesf eld 

Evaluation  Criteria  needs  input  to  avoid  working  in  vacuum. 


Elzer 

Each  subgroup  has  worked  according  to  implicit  design  criteria. 
Bowke  r 

But  I believe  that  no  agreement  exists  on  priority. 

Ichbiah 

This  group  has  not  the  manpower  to  make  a serious  effort  on 
evaluation  criteria.  Therefore  we  can  only  define  ourselves 
relative  to  Tinman  and  even  this  represents  a lot  of  work. 

We  cannot  possibly  do  better.  It  is  sad  hut  true. 

El  zer 

This  would  be  job  of  Eval.Crit.  group,  but  they  are  not 
here  to-day. 

De  Morgan 

M.  Levy  was  going  to  send  papers  but  did  not. 

El  zer 

We  have  now  got  onto  Evaluation  Criteria  so  let  us  take 
the  appropriate  item. 

Evaluation  Subgroup  Report. 

Elzer 

M.  Levy  was  suddenly  called  to  other  business.  ]i  was  uol 
possible  to  arrange  a proper  meeting  since  only  two  people  were 

there. 

We  still  have  staffing  problems.  Also  we  must  take 
M.  Ichbiah' s suggestion  about  Tinman. 
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Elzer 

My  explanation  of  difficulty  of  Eval.Crit.  is  because  the 
subject  is  more  difficult,  and  maybe  not  so  attractive.  Also 
other  Group  Chairmen  naturally  want  the  best  men  on  their  group. 

So  we  must  ask  Subgroup  Chairmen  to  be  willing  to  part  with 
persoruie  1 . 

Howker 

Evaluation  criteria  subgroup  being  asked  to  define  criteria 
after  definition  is  well  advanced.  This  is  unreasonable. 

Also,  because  group  is  small  there  is  little  incentive  to  join  it. 

Skinner 

All  the  more  reason  why  subgroups  must  produce  reports. 

Ichb iah 

Again  I insist,  we  have  no  hope  of  doing  anything  apart  from 

Tinman. 

Robe  r t 

Much  discussion  on  Tinman.  About  dOjS  is  acceptable. 
Difference  of  view  is  surprisingly  small. 


K L y.e  r 

Unfortunately,  M. Robert's  view  is  based  on  a paper  which  lias 
never  been  distributed.  We  should  distribute  this  paper. 

Are  you  and  M.Malgardis  willing  to  do  this? 

Malgardi s 

This  has  been  distributed  to  attendants  of  the  Purdue  International 
meeting.  I can  distribute  It. 

Elzer 

I will  make  proposals  for  Eval .Cri t. Group,  by  thinking  of 
names  of  people  who  could  go  onto  the  Eval.Crit.  group. 

Timmes  to l d 

We  do  intend  to  make  our  criteria  explicit.  We  have  started 
and  we  need  further  discussion  probably  in  lime.  Will  produce 

draft  proposal,  by  June. 

Elzer 

Whut  about  l/O  subgroup  and  Algorithmic? 

Ve rrmis  I 

We  have  not  considered  this. 

Cha  Line  rs 

We  have  a lot  of  "round  to  eo\er  and  r .*i;ink  our  first 
priority  is  to  complete  kern-vl  and  look  at  extensions.  We  have 
no  time  for  something  else,  and  l cannot  commit  the  group  in 
completing  this. 


Elzer 


This  would  be  good  but  I am  not  sure  there  is  enough 
effort  available. 

The  important  thing  is  to  get  this  group  going  again. 
I would  like  to  close  this  discussion. 


Report  of  Tasking  Group 

Ti mines  fe  Id 

li  discussions : 

1.  Modula. 

2.  LTPL-E/353 • CTI  Tasking  paper. 

3.  Distributed  intelligence. 

lt.  Design  criteria. 

1)  Modula  - decided  this  was  too  low  Level  for  LTPL. 

Could  be  basi  for  implementation. 

2)  LTPL-E/353.  long  discussion.  Discussions  on: 

i)  Nesting  of  PCE’s 

ii)  Access  rights 

iii)  Events 

iv)  Immediate  tasks 

v)  Statements  on  P/A’s. 

i)  Nesting  of  PCE's  desirable  with  very  complex 

problem  (100's  of  PCE’s)  for  better  structure. 

For  smaller  applications  a good  subset  may 
disallow  this. 

ii)  Access  Rights.  Possibility  of  defining  access 
rights  statically.  This  is  job  of  Algorithmic 
group.  Dynamic  access  of  common  data  by  a P/A 
with  the  right  to  do  so  is  job  of  tasking  group. 

iii)  Events  - not  necessary  in  addition  to  semaphores. 

iv)  Immediate  tasks.  Purpose  of  these  would  be  to 
split  an  interrupt  indicating  one  of  a series  of 
happenings  into  a set  of  Nifterent  interrupts. 

We  were  not  sure  where  to  place  this. 

v)  Needed  clarification  of  these  and  their  effect,  on 
PA  ’ s . 


3) 


Distributed  intelligence.  There  is  a wide  spread  of 
systems.  One  where  the  operating  system  of  each  element 
only  know  each  other  as  a peripheral.  Communication 
reduces  to  l/O.  Other  extreme  is  where  operating  system 
is  evenly  spread  over  all  elements  in  the  networks.  An 
in-between  is  where  the  operating  system  is  spread  but 
the  programmer  has  to  follow  restrictions  when  programming 
a PCE  to  be  executed  on  any  processor.  It  was  thought 
by  some  that  these  restrictions  may  disappear  in  time. 

We  want  to  discuss  these  topics  with  TCS  viz:  Operating 
Systems  on  Distributed  Systems. 

Either  extreme  case  is  invisible  ;uid  has  no  effect  on 
tasking  group.  In  in-between  case,  tasking  group  would 
have  to  define  limitations. 

*»)  Design  criteria.  Working  paper  by  M.  Kronental. 

First  contained  design  goals. 

1.  Reliability. 

2.  Readability. 

3.  Portability. 

*».  Efficiency. 

5.  Conceptual  simplicity. 

Having  decided  order  of  priority  of  these  goals  we  need 
more  specific  functional  requests. 

Informal  talk  with  M.  Lallve.  We  will  have  joint  session 
at  ISPHA.  Prepared  by  sending  papers  to  group  chairmen. 

Kronental 

I wish  to  disagree  about  description  of  MODULA.  It  is 
not  best  to  describe  it  as  low-level,  rather  its  primitives 
are  insufficient. 

Elzer 

Tome,  insufficiency  is  more  unfavourable  than  low-level. 
Timmes  feld 

1 think  this  is  just  a verbal  disagreement,  I think  it  is 
agreed  that  it  is  not  suited  to  the  purpose  of  LTPL. 

One  objection  is  that  synchronization  is  not.  secure  enough. 
Shared  data  can  be  accessed  in  an  unsale  way. 

Frogga 1 t 

I cannot  be  categorical  about  tins. 


Elzer 

I want  to  see  these  statements  proved. 

Kronental 

MODULA  allows  outside  programs  to  read  the  data 


of  a module. 
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T inline  s fold 

1 did  not  i;et  impression  that  WLrth 
as  an  application  Language,  rather  it  is 
operating  systems. 

Elzer 

I have  had  this  confirmed  as  regards  original,  design 
criteria  from  a co-worker  of  Wirth.  StiLl  this  doesn't 
mean  it  hasn't  further  application.  i have  I he  impression 
that  monitors  are  very  secure. 

Timmesf eld 

No  1 don't  say  monitors  are  insecure,  hut  MODULA  allows 
data  access  not  allowed  by  strict  monitors. 

Blzer 

We  must  have  proof  of  inadequacy  of  MODULA. 

Howker 

Surely  the  group  have  not  to  analyse  all  possible  languages? 

E 1 zer 

Yes  but  MODULA  has  many  advocates. 

Timmes  fe Id 

Not  many  and  they  were  not  at  meeting. 

Skinner 

Main  objection  was  that  primitives  were  at  too  low  a level, 
allowing  too  many  solutions  to  same  problem. 

Kronental 

Question  is  : Is  MODULA  a good  approach  to  an  LTPL  Kernel? 


thought  ol  MODULA 
for  programming 


Elzer 

I would  like  a decision  on  whether  the  Monitor  concept  is 
a sufficient  one  for  the  LTPL  tasking. 


A discussion  on  mel t-of-bes t- feat uros  again  followed. 
Ichbiah  and  Dowker  both  advocated  that  since  we  have  qualified 
and  modified  the  term  so  much  that  we  should  by  now  reject  it. 
Elzer  expressed  its  importance  in  guarding  against  being  thought 
academic . 

M.  Ichbiah  suggested  a motion  to  drop  any  mention  of 
me  1 t-of-bes t-features . M.  Roberts  seconded  and  it  was  deferred 
until  next  meeting.  He  then  asked  Dr.  Timinesfeld  if  a report 
would  be  produced  detailing  shortcomings  of  MODULA. 

Timinesfeld 

Our  policy  with  new  languages  is  to  discuss,  express  an 
opinion  tuid  minute  it.  We  do  no  more  and  if  anyone  wishes  to 
advocate  a language  he  must  appear  and  state  his  case. 
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E I zer 

Shortest  way  to  deal  with  this  is  formally.  TAG  demanded 
snapshot  and  subgroup  chairmen  were  asked  to  prepare  reports. 
These  were  revised  at  Meeting  in  Dee.  1*176  and  final  copies 
came  in  early  Jan. 1977.  Also  1 prepared  a hasty  paper  Tor 
Sept.  TAG  meeting  and  1 received  criticisms  from  subgroup 
chairmen  and  have  revised  it  according  to  criticisms.  I would 
like  to  meet  subgroup  chairmen  after  this  meeting  to  discuss 
with  them.  Only  alternatives  are  discuss  it  now  which  I am 

sure  nobody  wants.  i will  briefly  describe  structure. 

There  are  3 parts; 

1.  Overview  as  in  LTPL  E/362. 

2.  Algorithmic  subgroup  report. 

3.  Eval.Crit.  " " 

‘k.  I/O  " " 

5.  Tasking  " " 


These  are  exactly  as  received  by  chairmen, 


Discussion  of  TAG  modifications  to  Pro  jet.  Plan, 


TAG  meeting  after  LTPL  Dec.  meeting.  General  reception  of 
Project  Plan  was  favourable  but  some  criticisms. 

1.  It  doesn't  cover  all  aspects  of  project. 

This  is  true  and  was  defended. 

2.  Not.  enough  reference  to  Operating  System  interface 
in  language  skeletons.  So  1 have  added  a short 
section  to  take  care  of  this.  It  is  felt  that  the 
wording  will  need  modifying.  Main  point  was  to 
avoid  divergence  between  LTPL  ami  current  operating 
systems  interfaces. 

Chalmers  asked  if  TAC  wanted  report  for  next  meeting 
and  answer  was  Yes. 

Preparation  for  ISPRA 

ELzer 

-We  are  expected  to  give  a TC3  presentation  at  ISPRA.  Perhaps 
we  can  find  problems  which  show  inadequacies  of  other  languages. 
This  was  thought  to  be  perhaps  to  aggressive. 

The  meeting  were  informed  that  expenses  for  ISPRA 
should  be  paid  by  EEC. 

Other  Technical  Matters 


Elzer 

A paper  by  Roberts  on  Re-drafting  of  Tasking  Proposals  has 

no  number. 

LTPL-K/^Ol  was  assigned. 

Meeting  closed  at  1810  hrs. 
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Minutes  <>l  business  Meeting  2nd  February  1977 

Meeting  opened  at  9.00  a. in. 

Approval  ol‘  Agenda 

Two  items  added: 


1.  Status  of  1)01)  project  - report  by  Mr.  Rommler. 

2.  Discussion  of  meeting  after  next. 

Approval  of  Minutes 

Minutes  of  35th  - corrections  to  be  sent  to  Dr.  Gilbert. 

Dr.  Wegner  pointed  out  that  distribution  of  the  PEARL  I/O 
description  was  not  possible  now,  and  some  way  must  be  found 
to  expedite  this.  This  fact  contradicts  a statement  in  the 
minutes  which  must  be  altered.  M.  Robert  requested  para,  on 
page  19  to  be  deleted  since  it  was  not  recorded  in  proper 
context.  Mr.  Chalmers  suggested  removing  the  Appendix  A. 

It  was  felt  that  this  information  should  not  be  distributed 
world  wide.  However,  Mr.  Elzer  pointed  out  that  discussions 
in  the  main  text  were  just  as  problematical.  Mr.  Elzer 
suggested  that  para. 21  and  the  appendix  be  removed  and  replaced 
by  a neutral  summarising  paragraph. 

Mr.  Timmesfeld  moved  to  keep  the  minutes  as  they  are. 

Mr.  Chalmers  pointed  out  that  Mr.  Sokol  was  asked  to  keep  the 
matter  confidential.  M.  Robert  asked  whether  the  paper  could 
harm  the  project.  After  some  discussion,  it  was  decided  to 
leave  the  35th  minutes  as  they  are,  but  in  future,  it  should  be 
agreed  that  confidential  discussions  be  unminuted  by  agreement 
of  the  whole  meeting. 

Various  other  modifications  were  suggested,  whose  detail 
need  not  be  recorded. 

M.  ichbiah  suggested  a more  limited  distribution  of  Minutes 
but  the  Chairman  pointed  out  that  there  were  agreements  within 
Purdue  International  which  prevents  this. 

It  was  agreed  that  the  closing  date  for  amendments  to  the 
3r*th  and  T5th  Minutes  was  28.2.1977. 


Report  of  Planning  Group 
Elzer 

Stains  Report 

First  discussion  how  to  continue  with  Snapshot  report. 

The  paper,  (tor  description,  see  minutes  of  technical  plenary) 
will  be  distributed  to  aLl  on  A-list  and  C-list. 
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Discussion  on  TAC 

(See  Technic a 1 Meeting  Minutes) 

A proposal  was  made  to  chani'e  the  name  of  the  project. 

Malagard  Is 

The  name  is  not  an  important  issue.  A paper  was  produced 
by  the  commission  stating  that  "LTPL-E  should  he  the  main  source 
of  information".  This  was  objected  to  (mainly  by  IK  delegates) 
who  also  suggested  tiie  name  ERTL. 

Status  of  Project,  within  EEC 

E 1 z e r 

Dr.  Diettrich  informs  us  of  another  small  delay  in  the 
COREPER  who  wish  to  extend  the  competence  of  the  Comite 
Representative  to  cover  the  project.  It.  is  hoped  to  get 
go-ahead  hy  1st  March  1177.  The  project  leader  job  has  been 
advertised  and  is  now  closed  to  applicants. 

Co-operation  wi  th  other  groups 

This  really  concerned  TC8.  Difficult  to  establish  the 
exact  feelings  between  the  groups.  An  informal  meeting  was 
held  with  Dr.  Timmesfeld  (see  report  of  Tasking  group  in 
Tech.  Plenary  minutes). 

Detailed  live- laws 

Several  sets  exist: 

1.  International  Purdue  Bye-laws  - rather  large. 

2.  Smaller  set  of  LTPL-C  bye-laws,  mainly  to  enable 
letter  ballot. 

3.  When  EEC  contacts  started  (2  years  ago)  more  detailed 
bye-laws  suggested  to  cover  the  working  relationship 
between  LTPL-E  and  EEC.  M.  Malagardis  produced  a set, 
revised  by  Chalmers  and  Elzer  and  then  the  work  was 
suspended  until  the  relationship  settles  down. 

Although  it  is  progressing,  it  is  not  felt  yet  that 

the  time  is  right  for  new  detailed  bye-laws. 

So  it  is  suspended  again. 

TAC  Reports 

Mr.  Chalmers  suggestion  for  written  reports  on  TAC  meeting 
was  accepted  in  principle,  but  si  t nation  on  what  ma\  be  distributed 
is  not  clear. 

Minnies 

Discussion  on  minuting  possibly  confidential  discussion 
took  place  without  any  conclusion. 
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For  i nlormu  l i on,  all  EEC  decisions  arc  reported  in  the 
Official  Periodicals  of  the  Member  States, 

Robert 

With  respect  to  the  minutes,  the  problem  is  caused  because 
the  usage  of  the  minutes  has  changed.  Previously  they  were 
only  read  by  active  members  and  so  a relaxed  attitude  could  be 
taken,  for  example  in  including  humorous  sections.  Now  the 
readership  has  changed  we  need  to  be  more  careful  about  the 
minutes.  Perhaps  we  need  some  internal  minutes  plus  a summary 
of  these  for  external  use.  The  draft  minutes  would  be  a 
temporary'  life. 

Chalmeps 

Formal  minutes  are  difficult  since  our  meeting  is  informal. 

M.  Robert  agreed  to  try  to  produce  a digest  of  the  36th 
meeting  minutes. 

Mr.  Bowker  suggested  taking  up  Mr.  Elzer’s  idea  to  separate 
technical  and  business  minutes  and  to  exclude  non  LTPL-E  members 
from  (he  Business  meeting. 

Mr.  Rummler  felt  that  this  would  make  co-operation  difficult. 

M.  Robert  thought  that  his  idea  was  better  as  long  as  DOD 
were  careful  not  to  distribute  (he  detailed  minutes.  Some 
division  of  the  A-list  would  be  needed. 

M.  Robert  formulated  this  agreement  to  produce  both  the 
usual  minutes  and  an  official  precis  into  a motion  which  was 
unopposed . 

Distribution  was  discussed,  for  condensed  minutes.  First 
draft  only  to  people  present.  After  approval  they  could  be 
given  wide  distribution. 


Report  on  DOD  progress 
Ruminle  r 

This  is  an  informal  status  report.  A statement  from 
Col.  Whitaker  underlines  the  importance  of  < u-ope ra t i on . 

In  particular,  tie  want'd  clarification  at’  why  LTI’l.  consider 
a Process  Language  as  a different  problem  from  Tinman. 

He  can  still  see  no  real  difference  between  requirements  for 
military  and  industrial  control  applications. 

We  have  now  completed  an  evaluation  of  23  languages: 

FORTRAN,  COBOL,  PI,/ 1 , llAL/S, 

T AC  POL,  CMS- 2,  CS-'i,  SPL./l, 

J-3B,  d-73,  Algol  Co , Algol-68, 

CORAL- 66,  PASCAL,  SiMULA-67, 

LIS,  LTR,  UTL/2,  EUCLID, 

PDL/2 , PEARL,  MORAL,  EUL-1. 


j 
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20  contractors  evaluating  these  languages  against  Tinman 
requirements.  Evaluations  received  in  Oct/Nov  1976  and  had 
about  1000  comments  on  Tinman.  Decision  made  lor  interim  list 
of  languages  to  narrow  scope  lor  projects  starting  now: 

FORTRAN  COBOL  TACPOL  CMS  2 J3  J73  SPL-I 

This  is  to  prevent  proliferation  ol  languages  being  used. 

Evaluations  correlated  in  December  1976. 

Basic  results: 

1.  No  language  met  enough  requirements  for  selection  now. 

2.  A single  language  could  be  constructed. 

3.  This  language  most  likely  would  be  a modification 
of  an  existing  language. 

b . The  proposed  basis  for  further  development  is  the 
language  families  PL1,  Algol-6S,  PASCAL. 

IRONMAN  produced  in  Feb. 1977,  taking  all  comments  into 
account.  This  is  approved. 

On  1st  Jan. 1977,  economic  analysis  started  to  discuss  wider 
issues  - economic,  managerial  - and  to  assess  impact  of  adoption 
of  new  language  from  these  angles. 

Recommendation  that  6 contractors  produce: 

1.  Informal  language  design  - with  syntax. 

2.  Semantic  definition  - similar  to  axiomatic  PASCAL. 

3.  Draft  user  manual. 

b . Prototype  corapiler/interpreter. 

This  effort  goes  from  1st  May  to  1st  September. 

After  this  a 1 -month  evaluation  to  narrow  down  to  3 
contractors  to  develop  more  complete  implementation.  Also 
Steelman  will  be  then  produced.  After  November  things  are 
indefinite.  Lronman  will  be  distributed  to  all  LTPL-E  members 
as  will  Cornell  workshop  minutes. 

M.  Robert  expressed  "warm  approval"  of  the  DOD  co-operation. 


E t/<» r 

Is  it  possible  to  feed  back  response  to  criticisms  of  Tinman? 

I'm  min  l »■  c 

Not  really  possible  to  respond  to  all  the  in;my  comments. 

The  Iron  Man  will  contain  the  effective  response, 
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Mr.  Barnes  read  out  a summary  of  Lhe  changes  incorporated 
in  Iron  Man.  It  was  only  a draft  and  is  not  minuted,  the 
official  document  will  appear  shortly. 

Elzer 

I am  interested  in  this  basis  for  future  development  of 
the  families  of  Algol-68,  PL1,  PASCAL.  Why  was  this  decision 
made? 

Itummle  r 

Evidently  felt  that  these  families  cam  nearest  to  meet  the 
requirements,  so  that  these  were  the  best  frameworks  for  future 
works . 

Elzer 

Can  compilers  really  be  by  September? 

Rummler 

Very  likely  may  only  be  a skeletal  compiler  - unlikely 
to  be  complete. 

Elzer 

Can  a document  be  distributed  about  DOD? 

Kummler 

There  is  a Project  Plan  but  I do  not  know  yet  what  the 
distribution  will  be. 


Discussion  of  General  Situation 
Elzer 

Are  there  any  further  comment s/suggestions? 

Skinner 

With  respect  to  the  controversial  statement  objected  to 
by  TAG,  what  is  the  status?  Wha t is  TAG  * s status? 

Malagardis 

The  new  wording  is  more  or  less  accepted.  TAC  has  no 
official  status  whilst  project  has  no  official  status.  Still 
TAC  does  exist. 

Timmesf eld 

My  impression  is  that  TAC ' s formed  to  get  advice  on  special 
projects.  Since  LTPL  does  not  yet  exist,  TAC  cannot  be  fully 
official . 

Discussion  turned  to  differences  between  DOD  and  LTPL. 

Mr.  Tiinmesfeld  felt  that  the  difference  was  reducing  with  greater 
emphasis  in  Iron  Man  on  Parallel  Processing  and  Input  Output. 

ttober  t 

If  Iron  Man  is  more  specific  in  areas  where  LTPL  decisions 
are  still  pending  this  would  affect  our  work.  This  could  be 
much  quicker  if  at  least  copies  could  he  sent  to  Chairmen. 
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Uumm l e r 

Draft,  copies  have  been  sent  to  key  L.TPL  members,  but  I have 
not  got  the  list.  Unfortunately,  delays  in  posting  are  again 
presenting  a problem. 

Kl/.er 

Our  relationship  to  other  TC's  is  still  worth  discussing. 

A more  technical  general  position  paper  for  TCI  would  be  desirable 
Obviously,  this  would  overlap  with  other  work  but  still  would  lie 
a good  idea.  Main  danger  is  that  the  author  could  apply  a one- 
sided view.  So  it  would  have  to  he  approved  by  aLl  chairmen. 

Malugurd i s 

Nothing  shows  that  individual  studies  cum  Id  be  integrated 
into  a full  scale  report  which  is  what  was  needed.  So  1 suggest 
to  Layton  to  release  funds  to  produce  sueh  a report. 

done  s 

What  we  want  is  surely  something  very  similar  to  Tinman. 

Howke r 

l doubt  it'  anyone  objects  in  principle,  but  can  we  settle 
the  details  now. 

Malaga i d is 

Snapshot  reports  are  only  intended  for  non- technical  people. 
More  depth  needed  for  someone  to  find  out  briefly  the  technical 
work  of  the  committee. 

K 1 ze  r 

l think  the  idea  is  accepted.  I cannot  see  how  we  can 
finalise  details  before  ISPKA.  Could  M.  Malngardis  write  down 
his  ideas  and  distribute  them  to  planning  group  and  also  ask 
Layton  about,  possibility  of  money? 

Cha Imo is 

I accept  the  proposal  in  principle,  tint  can  we  really 
.cnv  ; ,i  i y hope  for  funds?  Past  e\per  ieuce  is  not  encouraging. 

M /i*i 

I .int'iiu;’ e Compu i i s.*n  was  loaded  and  others  were  voluntarily 

i i<*  us.  iwe  to  greater  priority  of  items  in  August  76 

• . • *•  i . :•  1 1 to  KKC.  1 feel  that  the  chances  are  quite 

, * worth  trv  l in  • 
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Software  Management  Conference 

Elzer  — 

This  is  in  London  2lst-22nd  March  l‘>77.  Participant- foe 

is  high  £135  + VAT  which  may  cut  out  some  members. 

Other  conferences: 

ISPRA  provisional  information  sent.  Details  iucli  tig 
transport  details  will  be  sent  in  good  time. 

Two  other  meetings  in  H.S.  were  notified  by  the  Chairman. 


Mailing  list,  and  paperlist: 

Mailing  list  was  check  O.k. 

A - gets  everything 

C - invitations  + important  papers 

0 - invitations  only. 

Paper  list.  Not  everybody  received  updated  paper  list. 


A. 0.11. 
llowke  r 

Could  I raise  the  possibility  of  2-day  meetings? 
It  was  agreed  to  vote  on  this  at  ISPRA. 


Next  Meeting 

Following 

Following 


ISPRA  March  3Dth 
Hrussels  June  1st 
llrussels  Sept. 3th 


April  1st 
June  3rd 
Sept.  7 th 


Meeting  closed  at  1200  hours. 
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Apologies  for  absence  received  from: 

G.  BIANCHI 

Bundesanstalt  fUr  Flugsicherung 
R.  GILBERT 

H. F.  HARTE 
J.D.  ICHBIAH 

M.  INDERST 
J.  LEVY 

N.  MALAGARDIJ 

I. C.  PYLE 

D. N.  SHORTER 
I.C.  WAND 

E.  WEGNER 
H.B.  WILLIAMS 
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Technical  Session  2.6.1977,  14.00 

T1  Approval  of  Agenda 

The  agenda  was  approved. 

Mr  Elzer  distributed  copies  of  transparencies  he  had  used 
in  a presentation  at  Eurocontrol. 

Two  new  members  were  present: 

1.  F.  Krella,  Eurocontrol.  Mr.  Krella  was  attracted  to  LTPL/E 
by  Mr.  Llzer's  presentation . lie  is  responsible  for  systems 

and  support  in  Eurocontrol.  Eurocontrol  has  been  interested 
for  ten  years  in  languages  for  real-time  systems  and  has 
done  some  research  in  this  area. 

2.  I.  Smith,  DEC.  Mr.  Smith  is  replacing  Mr.  Skinner.  He  works 
on  real-time  systems  and  languages. 

T2  Algorithmic  Subgroup  Report  by  Mr.  Chalmers 

The  subgroup  was  attended  by  only  5 people.  Five  of  our  regular 
members  were  unable  to  come  but  we  welcomed  the  transfer  of 
Mr.  J.  Barnes  to  our  subgroup. 

We  started  as  usual  with  approval  of  the  minutes  of  our  last 
meeting  and  review  of  actions  arising. 

The  changes  and  additions  to  our  Algorithmic  State  of  the 
Art  report  made  during  the  March/April  meeting  were  reviewed. 

As  a result  we  will  be  able  to  distribute  this  report,  giving 
the  Algorithmic  State  of  the  Art  up  to  April  1977,  to  the 
A-list  within  the  next  few  weeks  as  a replacement  for  paper  320. 

We  then  processed  position  papers  on  our  last  two  'deferred 
topics'  namely 

Static  Shared  Storage 
Array  Dimensions. 


J 


Most  points  of  the  former  were  agreed  and  fundamentals  were 
established  for  the  latter.  The  results  will  be  reviewed  in 
our  draft  State  of  the  Art  report  in  October. 

The  first  half  of  the  second  session  was  taken  up  by  a dis- 
cussion of  the  project  status  and  new  proposals  reported  at 
and  formulated  within  the  Planning  Group  meeting.  This  provided 
feedback  for  the  Planning  Group  and  gave  the  opportunity  for 
views  to  be  expressed  at  the  business  part  of  the  Plenary. 

The  remainder  of  the  session  was  taken  up  by  a joint  meeting 
with  the  Tasking  Subgroup.  The  objective  was  to  try  to  identify 
any  'grey  areas'  between  the  scopes  of  the  two  subgroups  and  to 
decide  which  group  should  handle  such  points.  The  paper  Nr.  366 
"Synchronisation  and  Structuration  Tools  for  Algorithmic  Problems" 
by  Mr.  Deschizeaux  was  taken  as  a starting  point. 

Mr.  Timmesfeld  stated  in  the  current  Tasking  Proposals  task 
creation,  activition,  waits  etc.  are  explicit  . nence  the  user 
must  decide  how  and  where  to  invoke  them  and  not  expect  a very 

high  level  compiler  to  do  this  for  him.  The  Tasking  Subgroup 
have  considered  seme  implicit  tests  but  decided  that  they 

were  too  costly  at  least  with  present  techniques. 

Mr.  Chalmers  proposed  that  the  example  on  page  4 of  paper  366 
should  be  taken  as  a sample  problem  for  the  Tasking  Subgroup, 
giving  solutions  for  both  the  monoprocessor  and  three  pro- 
cessor cases.  He  asked  if  this  could  be  done  by  the  next 
meeting.  Mr.  Timmesfeld  accepted  the  proposal  and  Mr.  Roberts 
said  he  would  attempt  to  do  the  work. 

A discussion  on  'what  is  Algorithmic  and  what  is  Tasking?' 
led  to  the  following  conclusion: 

'Algorithmic  and  Tasking  statements  are  mixed  in  a 
program.  The  Tasking  statements  act  as  "punctuation" 
and  control,  with  the  Algorithmic  statements  serving 
as  "phrases"  in  between  expressing  the  sequential  pro- 
cessing within  an  activity'. 


r 
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V.'ith  regard  to  representation  of  the  Tasking  functions,  it 
was  agreed  that  the  Algorithmic  Subgroup  should  define  the 
syntax  from  semantics  provided  by  the  Tasking  Subgroup, 
however  the  Algorithmic  Subgroup  feel  that  they  can  only  do  this 
meaningfully  when  the  revision  of  the  Tasking  Proposals  of 
paper  243  has  been  done. 

V.ith  regard  to  Time,  the  Tasking  Subgroup  see  the  need  for 
absolute  time  and  elapsed  time.  The  Algorithmic  Subgroup  should 
propose  the  Data  Type  in  which  to  express  time. 

Discussion 

None 

T3  Report  of  Evaluation  Criteria  Subgroup  by  Mr.  De  Morgan 

Three  members  (but  the  same  three  as  last  time!). 

1.  Continued  review  of  IRONMAN  commenced  at  ISPRA  meeting. 

Each  point  was  examined  and  evaluated.  R.M.  De  Morgan  to 
produce  paper  to  be  edited  by  Eval.  Crit.  s/G  for  distri- 
bution to  Comm,  before  Sept,  meeting. 

2.  Mr.  Cohen  reported  on  Planning  Group  meeting  of  1 June. 

3.  Papers  have  been  received  (not  yet  discussed): 

Kronental:  "Some  Design  Criteria  for  Tasking  in  LTPL" . 

Chalmers:  "Comparison  o'  Overall  Functional  Requirements 

of  DoD-HOL  ai  7TPL  (European)". 


Reh : 


Functional  Requirements  for  PLIP". 
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Pyle : 


"Suggested  Technical  Design  Criteria  for  LTPL" 
(8  Oct.  76) 

"Revised  Technical  Design  Criteria  for  LTPL" . 


4.  Draft  list  of  design  criteria  was  not  prepared  because  of 
lack  of  time.  Mr.  Levy  and  Mr.  Cohen  to  prepare  paper  for 
discussion. 


Discussion 

Mr.  Elzer  has  recieved  a paper  from  Nigel  Jones  purporting 
to  be  a reply  to  Mr.  Whitaker's  publicity  handout  on  the 
DoD  project,  in  which  Mr.  Jones  expresses  skepticism  of 
the  value  of  informal  language  definition  and  of  the  possibility 
of  compiler  verification  without  formal  definition. 

Others  have  not  received  this  paper.  Mr.  Llzer  will  ask  Mr. 

Jones  if  the  paper  should  be  distributed. 

Mr.  Elzer:  What  are  the  results  of  your  discussion  of  IRONMAN? 

Mr.  De  Morgan:  I prefer  not  to  summarise  but  refer  you  to  our 
paper. 

Mr.  Barnes:  What  is  your  general  feeling?  Good,  poor  ...? 

Mr.  De  Morgan:  It  is  on  the  whole  consistent;  with  exceptions. 

Some  features  are  technologically  advanced 
compared  to  the  rest  of  the  language,  e.g. 
rigid  control  of  side  effects  against  freedom 
in  structures  and  use  of  the  heap. 

Mr.  Elzer:  Thank  you.  I am  pleased  to  see  this  subgroup  moving 
forward. 


Mr.  Chalmers:  Col.  Whitaker  said  at  ISPRA  that  he  saw  no 

difference  between  industrial  requirements  and 
DoD  requirements.  There  was  a request  for  paper 
from  those  disagreeing.  I have  prepared  a paper 
on  this  and  given  it  to  the  Evaluation  Criteria 
Subgroup . 

Mr.  De  Morgan:  It  looks  like  a useful  and  concise  statement 
but  we  have  not  yet  discussed  it. 


T4  Report  of  I/O  Subgroup  by  Mr.  Verroust 

We  met  with  only  2 members  after  reception  of  4 letters  of 
apology . 

However  we  worked  fruitfully  in  the  frame  of  our  agenda. 

1.  We  built  the  general  structure  of  an  evolutionary  I/O 
technical  status  report  containing  permanently  the  state 
of  our  work,  element  by  element. 

2.  After,  we  had  an  important  discussion  to  define  the  basic 
elementary  objects  propcsable  for  I/O  features  of  LTPL. 

And  we  proposed  a generalized  FILE  concept  defined  as  a 
special  class  of  "task"  or  parallel  activity  having  the 
properties  of  a generalized  I/O  physical  device. 

We  began  too  a discussion  on  I/O  elementary  primitives. 

3.  We  discussed  on  Planning  Group  Meeting. 

Our  analysis  of  I/O  part  of  IRONMAN  was  done  at  ISPRA' s 
meeting  and  spread  to  A-list  under  number  380.  We  didn't 
have  any  answer  or  comment. 


4.  We'll  have  to  plan  a joint  meeting  with  tasking  group  to 
compare  our  synchronization  needs  with  their  mechanism  in 
order  to  merge  the  similar  functional  objects. 

5.  And,  before  September  we'll  have  some  contacts  between 
subgroup  members  to  prepare  the  first  copy  of  our  state 
of  the  art  dynamic  report. 

Discussion 


Mr.  Kappatsch:  Considered  as  a task  a file  has  peculiar  properties  - 
Activation  is  by  an  I/O  statement  and  when  it 
terminates  it  issues  a connected  happening. 

Another  property  is  that  it  keeps  a memory  of 
previous  activations.  The  OPEN  and  CLOSE  of  I/O 
can  be  seen  as  bracketing  a set  of  activations 
with  synchronisation  properties  to  forbit  use  of 
the  file  except  between  the  brackets.  A second 
point.  A file  can  execute  code,  we  would  like  to 
pass  code  to  a device. 

We  hope  to  make  these  proposals  more  concrete. 

Mr.  Elzer:  An  example  problem;  PDP11  with  CAMAC  - to  read  some 
particular  register.  In  assembler,  the  solution  is  a 
single  instruction.  How  could  this  sort  of  problem 
be  solved  without  overhead. 

Mr.  Kappatsch:  This  is  an  example  of  passing  code  to  a file. 

Mr.  Timmesfeld:  The  question  is  unfair.  You  demand  a mapping 

onto  a particular  machine-code  without  overhead. 

Mr.  Froggat:  At  language  level,  communication  with  a task  and 
with  a file  may  be  similar.  The  compiler  can  in 
special  cases  replace  a communication  statement 
with  little  inline  code. 
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Mr.  Timmesfeld:  There  is  a probleiri  of  synchronisation  with  the 

end  of  an  I/O  operation. 

I I 

Mr.  Kappatsch:  We  have  considered  this,  as  mentioned  earlier. 

Mr.  Elzer:  A powerful  general  mechanism  is  good  for  complex 
cases  but  not  good  for  simple  cases  such  as  my 
case  of  one  assembler  instruction. 

Mr.  Timmesfeld:  It  cannot  be  just  one  instruction,  you  also 

have  reaction  to  an  interrupt. 

Mr.  Elzer:  Not  in  this  case. 

Mr.  Verroust:  One  could  for  example  request  return  of  status 
values  at  the  end  of  I/O. 

Mr.  Krella:  What  does  that  mean  in  high  level  language  terms? 

Mr.  Kappatsch:  Perhaps  this  problem  could  be  solved  by 
'special  controls'. 

Mr.  Elzer:  Then  it  wouldn't  be  machine-independant. 

On  another  computer  than  PLP11  a complicated  reading 
sequence  might  be  involved. 

Mr.  Verroust:  Our  concept  can  be  used  at  many  levels. 

There  will  be  a paper  available  before  the 
September  meeting. 

T5  Report  of  Tasking  Subgroup  by  Mr.  Timmesfeld 

The  meeting  opened  with  four  members,  rising  to  six. 

We  have  been  having  problems  with  the  minutes. 

Mr.  Smith  is  replacing  Mr.  Skinner  as  secretary  and  he  will 
try  to  retrieve  those  minutes  which  Mr.  Skinner  has  failed 
to  deliver. 


I!'!  .1  '.II  I.HW.J  .^1  .>  y.  m*  m JI'VVWIW  ' ■' 
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Two  technical  points  come  up  during  our  meeting  with  TC8  at 
ISPRA.  We  completed  our  discussion  on  these  with  the  deci- 
sions : 

1 . to  drop  dynamic  priorities 

2.  to  drop  enabling  and  disabling  of  interrupts. 

We  continued  the  discussion  on  distributed  processing  and 
its  influence  on  tasking.  Mr.  Timmesfeld  will  provide  a 
position  paper  by  the  next  meeting,  summarising  our  ideas 
so  far,  namely  that  the  programmer  must  provide  information 
on  where  tasks  are  to  run  and  that  there  must  be  restrictions 
on  the  information  exchange  between  tasks  running  on  different 
parts  of  the  distributed  system. 

A discussion  on  time  was  originated  by  an  interrupt  from 
Mr.  Barnes.  We  decided  (again)  that  we  recognize  two  kinds  of 
time,  elapsed  time  and  point  of  time,  i.e.  time  of  day,  per- 
haps with  date.  A discussion  of  possible  representations 
followed;  this  is  really  an  algorithmic  feature  and  was  handed 
over  to  the  algorithmic  subgroup  in  our  joint  meeting. 

This  morning  we  discussed  the  results  of  the  Planning  Group 
meeting.  The  planning  group  had  proposed  that  the  rate  of  working 
of  subgroups  could  be  increased  by  week-long  meetings  of  the 
contributing  members.  In  our  case,  a paper  should  be  produced 
summarising  our  work  to  date,  filling  some  of  the  gaps  and 
including  arguments  for  and  against.  This  paper  would  then  come 
to  the  full  commitee. 

About  3 such  working  weeks,  possibly  including  some  contact  with 
other  subgroups,  could  provide  a language  definition  suitable 
for  pilot  implementation. 

The  tasking  subgroup  would  like  the  opinion  of  other  sub- 
groups. 

We  concluded  with  a joint  meeting  with  the  algorithmic  group, 
already  reported  on  by  Mr.  Chalmers. 
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Discussion 

Mr.  Elzer:  The  write-up  of  tasking  proposals  has  been  pending 
for  a long  time.  The  proposal  of  longer  working 
meetings  is  interesting  and  should  be  pursued. 

Mr.  Timmesfeld:  We  see  such  a meeting  as  replacing  a normal 

one,  not  additional  to  it. 

Mr.  Elzer:  It  could  be  attached  to  a normal  meeting. 

Mr.  Timmesfeld:  Only  with  loss  of  time.  Less  than  a full  week 

becomes  inefficient,  since  we  need  some  start- 
up time,  perhaps  a day,  for  members  to  refamiliarise 
themselves  with  the  work. 

Mr.  Elzer:  We  used  to  have  six  meetings  a year  and  now  have  only 
3 1/2,  which  many  people  feel  is  not  enough.  The 
tasking  group  proposes  a further  reduction. 

Mr.  Timmesfeld:  Most  members  are  most  interested  in  subgroup 

work.  I think  plenaries  take  up  too  much  time, 
and  so  does  Mr.  Chalmers. 

Mr.  Barnes:  So  do  I. 

Mr.  Chalmers:  I did  suggest  spending  a higher  proportion  of  our 
time  on  subgroup  work.  It  is  certainly  worthwhile 
for  the  tasking  group  to  have  a longer  meeting  for 
this  special  purpose;  it  is  not  so  clear  for  other 
groups.  I do  not  want  to  drcp  the  plenary  altogether. 

Mr.  Elzer:  This  'caucus'  meeting  was  my  suggestion,  but  I ex- 
pected an  additional  meeting  of  perhaps  3-4  tasking 
group  members. 
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Mr.  Timmesfeld:  Yes,  selected  membership.  As  a concrete  example, 

we  could  meet  in  September  - this  is  probably 
the  only  time  for  Mr.  Wand.  This  is  close  to 
the  full  meeting,  so  probably  noone  from  the 
caucus  would  attend  the  full  meeting.  Also,  we 
think  other  subgroups  could  benefit  from  such 
meetings . 

Mr.  Maddock:  You  could  hold  your  meeting  directly  before  the 
full  meeting. 

Mr.  Timmesfeld:  We  would  lose  one  day,  i.e.  20%;  really  more, 

because  of  start-up  time.  Perhaps  the  full 
• meeting  could  be  Friday  afternoon  only? 

Mr.  Maddock:  Friday  morning  only. 

Mr.  Elzer:  Is  the  idea  at  all  realistic?  Funds?  Who  meets  whom 
when  where? 

The  reduction  of  meetings  to  4 a year  was  not  uni- 
versally popular. 

Mr.  Barnes:  If  we  use  Friday  afternoon  for  the  business  meeting, 
we  have  1 1/2  days  for  subgroup  meetings. 

Mr.  Roberts:  Not  everyone  can  get  home  on  Friday  evening. 

Mr.  Helfert:  This  has  been  tried;  people  leave  early. 

Mr.  Barnes:  If  necessary  some  people  could  stay  over  Friday 
night.  Anyway  only  the  business  meeting  suffers. 

Mr.  Elzer:  Don't  underestimate  the  business  meeting. 

I also  find  Friday  afternoon  meetings  inconvenient. 
There  is  an  item  on  tomorrow's  agenda  for  meeting 
structure,  also  the  planning  group  can  discuss  it 
tonight . 


— 
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Mr.  Chalmers:  Discussion  in  the  algorithmic  subgroup  is  too 
exhausting  for  us  to  vise  a full  week;  also  we 
might  not  have  enough  items  to  fill  the  time. 

Mr.  Timmesfeld:  1 have  contrary  experience.  Many  companies  use 

this  method  in  development  work. 

Mr.  Chalmers:  It  doesn't  suit  me. 

Mr.  Llzer:  Are  there  any  technical  points?  I have  one. 

We  have  sample  problems  from  Mr.  Deschizeaux,  one 
is  counting  interrupts,  or  very  minimal  processing. 
Traditional  tasking  imposes  too  much  overhead. 

Mr.  Roberts:  The  overhead  is  not  very  high  with  the  second 
solution  on  the  board. 

(Refering  to: 

INTERRUPT  INT; 

SEMA  S;  INTEGER  I; 

TASK  T: 

L:  REQUEST  S; 

I : = 1+1  ; 

GOTO  L 
END  /*  T * / ; 

ACTIVATE  T; 

WHENEVER  INT  RELEASE  S;  ...) 

Mr.  Elzer:  (.00  microseconds! 

Mr.  Timmesfeld:  How  often  does  such  a case  arise? 

Mr.  Elzer:  It  is  30%  of  the  load. 

Mr.  Timmesfeld:  The  solution  is  in  any  case  not  complete. 

"I  should  be  increased  only  in  a critical 
section . 
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Mr.  Elzer:  In  my  case  the  processing  is  in  fact 
A(I)  :=  A(I)  +1  . 

I don’t  need  a critical  section,  because  it  doesn't 
matter  if  the  results  are  a bit  off. 

Mr.  Timmesfeld:  Leaving  out  synchronisation  is  not  suitable 

for  a safe  language.  The  synchronisation  over- 
head could  be  reduced  by  moving  it  outside 
the  loop,  but  then  the  loop  would  have  to 
include  a test. 

Mr.  Elzer:  This  problem  should  be  included  in  the  set  of  sample 
problems  and  must  be  solved  satisfactorily. 

Mr.  Timmesfeld:  Either  one  accepts  overheads  or  loses  safety. 

Mr.  Elzer:  One  could  introduce  access  rights 

1 . read  only,  change  disallowed 

2.  read  only,  change  (by  other  tasks)  allowed. 

Mr.  Froggat:  An  interrupt  could  occur  between  changing  2 words 
of  a multi-word  item  such  as  a floating  point 
number . 

Mr.  Elzer:  There  may  be  implementation  problems.  Me  need  ex- 
plicit interrupt-handshake  in  the  language. 

General:  disapproval  of  the  detailed  nature  of  the  discussion. 

Mr.  Elzer:  For  simple  things  there  should  be  simple  solutions. 

I am  convinced  there  is  an  acceptable  solution  to 
this  problem. 

T6  Replacement  of  'melt  of  best  features' 

There  had  been  no  response  to  Mr.  Elzer 's  request  for  written 
suggestions.  Mr.  Elzer  suggested  'melt  of  best  proven  prin- 
ciples'. Alternative  suggestions  in  the  course  of  discussion 
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were  'conceptual  evolution'  and  'proven  state  of  the  art'. 

There  was  a general  feeling  that  the  words  'melt'  and  'prin- 
ciples' were  not  quite  right.  'Principles'  could  perhaps  be 
replaced  by  'concepts',  'melt'  Ly  'integration'  or  'fusion'. 

'Best'  was  suggested  to  be  redundant.  Wo  decision  was  reached. 

T7  Other  technical  matters 

Mr.  Rummler  reported  on  the  state  of  the  DoD  project: 

The  DoD  wants  to  finalise  contracts  by  July  1st.  Mr.  Elzer 
and  the  subgroup  chairmen  are  invited  to  Washington  to  brief 
DoD  and  the  DoD  contractors  on  the  status  of  the  LTPL-E  work. 

They  think  July  13th  would  be  a suitable  date.  LTPL-E  is 
invited  to  join  in  the  evaluation  of  the  deliverables  of 
phase  1 and  of  further  phases.  Phase  1 will  be  completed  at 
the  end  of  this  year.  Evaluation  will  take  place  in  January 
1 978. 

Mr.  Barnes  and  Mr.  Maddock  had  information  that  phase  1 would 
run  from  Sept.  77  to  march  78.  Mr.  Rummler  could  not  confirm 
this.  The  RFP  had  been  out  on  23rd  April  and  the  intention 
had  been  for  phase  1 to  run  from  July  through  December. 

Mr.  Timmesfeld  thought  phases  2 and  3 were  on  too  narrow  a 
timescale.  Mr.  Rummler  said  he  expected  phases  2 and  3 to  be 
stretched. 

Mr.  Elzer  said  that  LTPL-E  would  not  be  able  to  meet  a deadline 
of  end  of  January  for  evaluation  of  phase  1 . He  also  asked  who 
would  pay  for  the  proposed  trip  to  Washington.  Mr.  Rummler 
stated  that  DoD  had  nothing  budgeted  for  this. 

Mr.  Froggat:  The  DoD  is  essentially  asking  for  evaluation  criteria 
from  LTPL-E.  Is  it  expected  that  contractors  would 
consult  LTPL-E? 

Mr.  Rummler:  If  they  like. 

Mr.  Froggat:  Will  LTPL-E  requirements  and  proposals  be  circulated 


to  contractors. 
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Mr.  Rummler:  No,  contractors  will  supply  their  own  expertise. 

Mr.  Barnes:  The  differences  between  our  requirements  and  those 
of  DoD  should  be  presented  to  DoD. 

Mr.  Timmesfeld:  One  difference  is  that  in  for  example  the  use 

of  embedded  weapons  systems  a special  purpose 
operating  system  could  be  written  in  the  lan- 
guage. In  our  case  a standard  operating  system 
would  be  part  of  the  implementation. 

Mr.  Rummler:  In  my  experience  software  is  produced  and  modified 
over  a considerable  period.  Some  common  modules 
may  be  used.  In  a process  control  environment 
there  may  be  some  software  developed  for  e.g. 
chemical  plant  which  could  then  be  used  by  other 
chemical  companies. 

Mr.  Timmesfeld:  We  do  try  to  produce  reusable  packages  but  up 

to  now  it  hasn't  worked  very  well. 

Mr.  Barnes:  I disagree. 

Mr.  Rummler:  In  my  experience  we  started  out  building  unique 

programs  for  each  ship,  aircraft  etc;  this  got  too 
expensive . 

Mr.  Chalmers:  If  a central  procurement  body  exists  control  is 

easier.  Independent  bodies  demand  so  many  special 
features  that  it  is  often  cheaper  to  redo  the 
whole  package. 

Mr.  Froggat:  The  LTPL  will  not  be  suitable  for  writing  operating 
systems . 

Mr.  Elzer:  Rather,  we  are  not  constrained  by  the  requirement 
to  be  able  to. 
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Mr.  Froggat:  We  are  eliminating  features  needed  for  this,  such 
as  enable/disable  interrupt. 

Mr.  Llzer:  Do  we  accept  this  invitation  for  July  13th? 

I think  so.  We  must  discuss  whether  we  can  meet 
that  deadline  and  what  we  can  present  there. 

Mr.  Timmesfeld:  What  was  meant  by  'briefing'? 

Mr.  Rummler:  A presentation  by  each  chairman  including  some- 
thing shown  on  a screen  which  we  can  take  copies 
of . 

Mr.  Barnes:  We  could  try  to  say  two  sorts  of  things 

1 . the  LTPL  requirement  are  so  and  so 

2.  we  disagree  with  IRON MAN  in  points  x,  y and  z, 
and  offer  alternatives. 

Mr.  Maddock:  The  paper  by  Pyle,  Ichbiah  and  me  will  be 
avaiable  by  July  13th. 

Mr.  Llzer:  Will  all  who  want  to  comment  on  IRONMAN  send 
comments  to  me. 

Mr.  Chalmers:  Also  to  subgroup  chairmen. 

Mr.  Quillin:  You  will  need  a preparatory  meeting. 

Mr.  Chalmers:  I will  propose  at  the  planning  group  meeting 
tonight  that  we  meet  3 or  *1  weeks  before  to 
prepare  a presentation  with  transparencies  etc. 

Mr.  Barnes:  Who  will  be  there?  \ 

Mr.  Rummler:  Half  a dozen  contractors,  probably  2 or  3 people 
from  each,  also  an  equivalent  number  of  DoD 
people . 
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I Business  Session,  June  3rd  1977,  9.15 

B1  Approval  of  previous  minutes 

The  minutes  were  accepted  with  minor  corrections. 

B2  Report  of  planning  group  and  discussion  of  possible 
reorganisation  of  LTPL-E 

The  planning  group  held  two  meetings  attended  by  Mr.  Chalmers, 
Mr.  Cohen,  Mr.  Elzer,  Mr.  Kronental,  Mr.  Layton  (part  only), 

Mr.  Thompson  (part  only), Mr.  Timmesfeld  and  Mr.  Verroust. 

Item  1 

It  was  reported  that  another  member  country  will  bring  criticism 
of  the  project  and  propose  changes. 

Mr.  Layton  asked  the  Planning  Group  to  propose  priorities  fcr 
LTPL-L  work  in  case  not  all  the  money  asked  for  in  the  last 
projebt  plan  becomes  available.  After  discussion  Mr.  Llzer 
prepared  a paper  which  was  discussed  in  the  second  meeting. 

This  paper  will  be  sent  to  Mr.  Layton  (see  Annex  1) . 

! 

Item  2 

There  was  a suggestion  that  cooperation  with  the  DoD  project 
should  be  formalised.  Gome  LTPL-E  members  already  work  with 
DoD.  This  led  to  difficulties  at  ISPRA  when  some  members  needed 
time  for  discussion  with  Mr.  Whitaker. 

Mr.  Elzer  proposed  that  part  of  LTPL-E  work  be  devoted  to 
cooperation  with  DoD  and  part  to  ongoing  LTPL  work.  The  planning 
group  reached  no  decision  and  would  welcome  expressions  of 
opinion  from  other  members. 

_ _ 


i 


-210- 


1 tem  3 

It  was  decided  to  accept  the  invitation  expressed  by  Mr.  Rummler 
during  the  technical  meeting  (T7)  for  Mr.  Llzer  and  subgroup 
chairmen  to  give  a presentation  in  Washington  during  the  week  of 
July  11th.  This  date  was  however  felt  to  be  too  close,  so  the 
group  requests  postponement. 

It  was  agreed  that  the  main  aim  of  the  presentation  should  be 
to  give  our  views  on  evaluation  criteria  and  work  in  this  area 
will  be  speeded  up  to  enable  us  to  give  more  information  on 
July  13th  (or  preferably  later). 

NB.  There  are  no  longer  any  complaints  about  American  lack  of 
cooperation  in  information  exchange. 

Item  4 

The  ISPRA  motion.  It  was  felt  that  this  concerns  mainly  LTPL-C. 
Mr.  Llzer  will  write  to  Mr.  Reh  about  it.  (See  Annex  2) 

Discussion  in  the  planning  group  led  to  the  conclusion  that  the 
wording  of  the  motion  was  too  rigid  and  that  it  lays  too  strong 
obligations  on  the  group.  We  should  find  out  what  IFIP  customs 
are  (we  are  an  IFIP  subgroup) . 


Discussion 


None . 

Mr.  Llzer:  I take  this  as  approval  of  the  prepared  paper  and 
hand  it  to  Mr.  Diettrich  for  typing  and  sending 
to  Mr.  Layton. 

B3  Contacts  with  ISO/TC97/SC5/WG1 - 1 PLIP 1 

Mr.  Llzer:  The  British,  French  and  German  national  standard 
organisations  have  produced  contributions  for  the 
ISO  group  on  industrial  control  languages. 


Mr.  Elzer  has  distributed  the  German  contribution 
to  the  A-list,  Mr.  Kronental  will  distribute  the 
French  contribution.  We  would  like  the  paper  sub- 
mitted by  BSI , authors  J.  Barnes  et  al. 

Does  Mr.  Barnes  permit  distribution? 

Mr.  Barnes:  The  chairman,  Mr.  Thompson,  is  responsible. 

Mr.  Elzer:  If  the  paper  may  be  distributed  please  send  it  to 
Mr.  Levy  for  distribution. 

We  should  also  discuss  possible  contacts  to 
CCITT.  Mr.  Whitaker  and  Mr.  Leyton  are  also  interested 
in  such  contact.  My  attempts  to  date  find  little  or 
no  interest  by  CCITT  in  cooperation.  They  have  pro- 
duced a language  comparison  which  some  of  us  have. 

The  planning  group  would  be  grateful  for  help  in 
arranging  a talk  with  CCITT. 

Mr.  Barnes:  I can  give  you  the  address  of  the  chairman. 

Mr.  Elzer:  I have  a letter  fi-om  Mr.  Pyle  proposing  better 
cooperation  with  IFIP  2.4,  of  which  Mr.  Ichbiah 
and  Mr.  Kronental  are  members. 

Mr.  Kronental:  I was  at  the  first  meeting  of  IFIP  2.4  at  ? 

in  the  south  of  France.  Many  well-known  people 
in  the  field  of  machine-oriented-high- level  - 
languages  were  present.  The  main  interest  is  in 
a two-level  language,  level  1 being  a conventional 
algorithmic  language  while  level  2 can  express 
implementation  details  such  as  memory  management, 
data  representation,  interfaces,  semas,  tasks. 

They  discussed  separate  compilation,  safe  use 
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of  pointers  (e.g.  in  the  algorithmic  language 
there  are  typed  references,  in  the  implementation 
part  these  may  be  mapped  onto  integers;  there 
have  to  be  rules  to  prevent  users  doing  tricks 
with  low  level  pointers.)  I have  just  recieved 
the  latest  book  from  WG  2.4  edited  at  IRIA  by 


Mr.  Teller:  They  also  work  on  instrumentation,  e.g.  of  code 

size  and  running  times  and  are  producing  standard 
programs  for  comparison. 

Mr.  Barnes:  Can  we  get  their  papers? 

Mr.  Kronental:  The  book  is  too  thick  to  distribute  to  the  A-list, 
There  is  no  microfiche  version.  The  book  is  sold 
by  IRIA,  I can  get  details  of  price,  how  to  order 


Mr.  Teller  and  Mr.  Maddock  reported  that  the  last  meeting  was 
in  Novosibirsk  2 weeks  before  and  that  one  was  planned  for 
August  8th  - 12th  in  Toronto. 


Mr.  Barnes  reported  that  anyone  would  be  permitted  to  attend  as 
an  observer,  but  could  become  a member  only  by  invitation. 

Mr.  Barnes  considered  however  that  a formal  relationship  between 
LTPL-E  and  WG  2.4  would  be  inappropriate,  as  they  work  with 
experimental  and  we  with  proven  features. 

Mr.  Elzer:  I have  been  approached  by  several  people  asking  why 
there  is  no  such  cooperation. 

Mr.  Teller:  Perhaps  we  should  invite  members  of  WG  2.4  to  give 

presentations  on  advanced  features  we  are  interested 


Mr.  Elzer:  The  main  thing  for  the  moment  is  to  find  out  where 
to  get  their  papers. 


Mr.  Elzer:  The  speed  with  which  we  are  getting  through  today's 
items  confirms  that  the  business  session  can  be 
compressed.  I propose  we  hold  the  business  session 
on  the  Friday  afternoon  of  the  next  meeting  as 
discussed  yesterday. 

General:  Agree. 

Mr.  Elzer:  I urge  subgroups  other  than  tasking  to  consider 
full-week  working  meetings. 

There  followed  discussion  on  the  best  site  for  such  meetings. 

One  possibility  was  the  EEC  establishment  at  Geel  about  60  km 
from  Brussels.  This  would  keep  participants  away  from  the 
distractions  of  the  big  city  and  useful  facilities  such  as 
photocopying  would  be  available.  On  the  other  hand  small  groups 
could  be  conveniently  accomodated  in  the  EEC  offices  in 
Joyeuse  Entree,  where  also  copying  facilities  are  available. 

Mr.  Diettrich  could  arrange  accomodation  there.  It  was  therefore 
agreed  to  hold  a working  meeting  of  the  most  active  members  of 
the  tasking  group  in  Brussels.  Proposed  members  were  Kronental, 
Roberts,  Timmesfeld  and  Wand.  September  would  probably  be  the 
most  convenient  time.  It  was  agreed  that  Mr.  Timmesfeld  would 
contact  the  above  named  members  and  arrange  a date. 

Mr.  Chalmers  said  the  algorithmic  group  would  at  the  next 
meeting  discuss  the  need  for  such  a working  meeting. 

Mr.  Verroust  thought  that  the  I/O  subgroup  would  have  staffing 
problems  for  such  a meeting. 
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Ma 1 1 i ng  L i s t , Paper  List 


Mr.  Elzer:  Don't  forget  the  new  paper  numbering  scheme. 

Mr.  Barnes:  I propose  the  readoption  of  the  old  scheme. 

One  cannot  now  know  whether  one  has  a full  set 
of  papers . 

There  was  general  agreement  that  the  new  scheme  should  be 
given  a longer  trial. 


36  Next  meetincrs 


Mr.  Elzer:  We  have  a meeting  planned  for  Sept.  12-14. 

There  are  two  diverging  proposals 

1 . more  meeting  for  more  work 

2.  less  meetings,  more  and  longer  subgroup 
meetings . 

The  tasking  subgroup  meets  in  September  and  those 
members  who  attend  would  not  attend  a full  meeting 
in  September. 

Moreover  we  can  have  only  one  more  funded  meeting 
this  year.  Do  we  want  to  shift  the  September  meeting 
to  a later  date? 

There  was  general  agreement  that  only  one  more  full  meeting  be 
held  this  year  and  that  it  be  later  than  September. 

The  exact  date  would  depend  on  holidays  in  France,  Mr.  Elzer's 
other  commitments,  the  ISO  meeting  in  November  etc.  Dates  were 
narrowed  down  to  3 possibles  which  were  then  voted  on. 


V 


-215- 


A vote  for  indicates  acceptability  of  the  date,  more  than  one 
for-vote  per  person  is  possible: 


17  - 

19 

Oct 

1 1 

for 

24  - 

26 

Oct 

8 

for 

26  - 

28 

Oct 

5 

for . 

Thus  17-19  October  was  adopted. 

Mr.  Chalmers  proposed  continuing  the  algorithmic  subgroup  meeting 
on  the  20th  and  21st.  Could  the  full  meeting  be  on  the  17th  - 
1 8th  so  that  subgroup  could  use  as  much  as  desired  of  the  rest 
of  the  week?  After  a little  discussion  a proposal  to  hold  the 
plenary  meeting  at  the  beginning  of  the  meeting  was  rejected 
with  only  3 votes  in  favour. 

In  summary: 

The  next  normal  meeting  is  from  17th  - 19th  October  with  the  full 
technical  session  in  the  morning  of  the  19th  and  the  business 
meeting  jn  the  afternoon. 

There  will  be  a special  tasking  group  meeting  in  September. 

The  algorithmic  and  I/O  groups  will  meet  17  - 18  and  20  - 21 
October . 

Proposals  for  the  meeting  after  October  were  25  - 27  Jan.  1978 
v/ith  11  votes  for  and  1-3  Feb.  with  6 votes  for. 

25  - 27  Jan.  is  accepted. 

B7  AOB 
None. 

Annex  1 List  of  First  v/ork  items 


Annex  2 Letter  from  Mr.  Elzer  to  Mr.  Reh  about  Ispra 

motion  on  cooperation  with  DoD  (to  be  provided) 
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COMMISSION 
OF  THE 

EUROPEAN  COMMUNITIES 

D i t «c  to  ro  f»  • Gam  ni  I 

Internal  Market  and 
Industrial  Affairs 

I1I-B-2 

l.TPL-E/PE  77060201 


Brussels 

OD/lv 


8th  June  1977 


JUSTIFICATION 


Proposed  list  of  first  work  items 
in  preparation  of  an  l.TPL-E  project 


In  view  of  the  continuous  delays  of  the  formal  adoption  of  the  l.TPL-E  project 
something  has  to  be  done  to  maintain  the  continuity  of  work.  It  is  therefore 
proposed  to  take  up  again  the  idea  of  "small  funded  pre-project  studies".  Of 
course  these  have  to  fit  into  the  framework  of  a subsequent  project  plan  and 
it  is  therefore  further  proposed  that  certain  parts  of  the  project  plan 
proposal  by  the  l.TPL-E  Group  in  September  1976  be  undertaken  as  such  studies 
(maybe  in  a modified  form). 


The  following  short  list  of  items  of  work  was  therefore  discussed  at  the 
meeting  of  the  planning  group  on  June  I,  1977  : 

1)  Writeup  of  l.TPL-E  work 

2)  Collection  of  sample  problems 

3)  Evaluation  of  Ironman 

4)  Identification  of  advanced  language  features 

5)  Identification  and  evaluation  of  I/O  mechanisms 

6)  Identification  of  Software  tools 

7)  Studies  on  1 anguage-to- language  translation. 


Provisional  adilrMi  Hue  ds  la  Lot  200.  B 1049  BruiMli  - T«l#|ihon*  735  00  40/7.15  80  40-  Telegraphic  eddrett  "COMEUR  Bru»*ai»' 

Tale*  21  B77  COMEU  H 


* 
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Thc  ordering  is  according  to  u "rating"  given  to  the  proposals  by  a kind  ot 
"straw  vote"  of  the  planning  group. 

Proposals  for  other  such  studies  are  welcome. 


EXP.  JiNATION  OF  WORK  ITEMS 


E 

I 

i 

) 

i 


1)  Writeup  of  LTPL-K  work 

The  "snapshot  report"  has  only  given  a very  brief  overview  on  activities 
and  achievements  of  the  I.TP1.-E  group.  Especially  the  technical  contents 
has  not  been  described  in  sufficient  detail. 

It  is  therefore  necessary  to  have  a paper  of  technical  nature  which 
describes  the  achievements,  decisions  and  problem  areas  of  the  comp  let  e 
I.TPL  at  the  current  point  in  time.  It  shall  neither  be  a re-invention 
of  work  already  done  nor  a kind  of  "mini"-languagc  - specification. 

Nevertheless  it  shall  have  an  integrating  effect  insofar  as  it  describes 
the  status  of  the  discussion  of  all  subgroups  in  a synoptic  way. 

For  the  reasons  given  and  in  order  to  achieve  maximum  continuity  and  effi- 
ciency we  recommend  this  work  to  be  done  by  the  most  active  members  of 
subgroups  in  the  form  of  caucus-meetings  of  e.g.  one  week  each. 


2 ) Collection  of  sample  problems 

Most  of  the  language  developments  until  now  have  suffered  from  the  tact 
that  definition  was  frozen  before  adequate  tests  of  the  useability  of  t ho 
language  could  be  undertaken. 


r i 


Interactive  design  with  test  implementations  before  the  final  definition 
would  be  the  best  remedy,  but  are  verv  unpopular  with  people  who  are  in 
control  of  money  for  development  work. 


r 
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It  is  therefore  proposed  to  collect  a set  of  sample  problems  which  shall 
be  t ested  for  its  reprcsentativity  by  user  polls  and  afterwards  used  for 
e.g.  evaluation  of  language  features  by  test  coding. 

This  study  could  be  undertaken  by  a user’s  group  or  by  a large  software- 
house  with  a lot  of  application  experience. 

3)  Evaluation  of  Ironman 

The  DoD-project  is  a fact  of  life  and  it  is  in  good  shape.  Nevertheless 
there  is  continuous  discussion  whether  its  outcome  will  satisfy  the  needs 
of  European  Civilian  Industry.  This  question  should  be  answered  only  on 
the  grounds  of  more  detailed  evidence. 

It  is  therefore  proposed  to  have  the  Ironman  document  reviewed  by  the 
LTPL-Group  (with  adequate  secretarial  support)  in  order  to  either  identify 
possible  differences  with  our  point  of  view  (and  give  solid  justifications 
tor  this)  or  the  possibility  of  adopting  the  document  for  our  purposes. 

4)  Identification  of  advanced  language  features 

The  art  of  designing  languages  has  made  progress  and  it  seems  that  certain 
problems  on  which  we  still  discuss  while  trying  to  solve  them  by  tradi- 
tional means,  do  no  longer  exist  when  using  more  modern  constructs. 

One  should  therefore  invest  some  manpower  in  identifying  modern  language 
elements  which  have  already  reasonably  demonstrated  their  implement abi 1 i t y 
and  promise  to  make  life  tor  the  user  carier. 

5)  Identification  and  evaluation  of  I /O-merhan i sms 

For  some  people  the  discussion  on  the  "right"  I/O-mechani sm  has  reached 
the  quality  of  a religious  issue. 

Given  the  scarcity  of  manpower  in  the  group  and  in  order  to  be  able  to 
make  a decision  on  more  solid  grounds,  several  existing  I/O  mechanisms 
shall  he  identified,  explained,  their  range  of  applicability,  their 


advantages  and  shortcomings  discussed.  They  should  be  clearly  different 
in  order  to  ensure  an  adequate  broadness  of  view. 

This  item  of  work  could  best  be  done  by  a research  institute. 

6)  Identification  of  software  tools 

This  item  should  give  some  case  studies  of  the  components  of  and  the 
interactions  in  a software  production  system  and  possibly  identify  the 
iterrelations  between  the  language  and  other  components. 

7)  Studies  on  language-to-language-translation 

As  a key  issue  for  the  success  of  the  whole  LTPL-adventure  always  an 
easy  transition  from  "old"  to  "new"  languages  has  been  mentioned. 

According  to  the  principle  that  decisions  should  be  taken  on  the  grounds 
of  identifiable  facts  a survey  on  successfull  (or  their  opposite)  cases 
of  language-to-language-trans lat ion  shall  be  undertaken. 


Annex  2 (Added  24th  Oct  77) 

The  matter  of  the  Ispra  motion  on  cooperation  with  DoD 
was  settled  without  Mr.  l'.lzer  writing  a letter,  by 
phone  calls  and  by  discussion  in  the  meeting  of  LITL-C 
at  Prudue  in  Oct  77,  when  the  motion  was  passed. 


* 


REPORT  OF  THE 

PROBLEM  ORIENTED  LANGUAGES  COMMITTEE 
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REPORT  OF  THE  POL  COMMITTEE 
INTERNATIONAL  PURDUE  WORKSHOP 


The  POL  Committee  has  made  a detailed  review  of  the 
languages  catalog  form  (POL-E)  which  will  be  used  to  gather 
information  concerning  POL's  from  implementors.  This 
language  catalog  will  be  organized  to  provide  information  to 
the  end  user  in  selecting  POL's  for  his  application. 

The  catalog  form  was  restructured  to  include  sections  on 
the  user,  the  implementor  and  general  topics. 

The  impact  of  micro  computing  technology  on  the  goals  and 
objectives  of  the  POL  committee  has  also  been  discussed  at 
length.  As  a result  of  this  discussion,  action  items  were 
generated  by  the  Regional  POL  Committees  as  follows: 

I.  POL-A  will  investigate  and  report  on  applications  of 
micro  computers  for  the  direct  implementation  of  POL's. 

LI.  The  work  of  POL-E  is  organized  as  follows: 

1.  A POL  is  not  only  a special  application  system  which 
contains  the  solution  of  a userte  (engineer^)  problem 
but  also  a high  order  language  which  enables  a user 
to  program  the  solution  himself  on  a very  high  level. 

2.  Therefore  POL-E  is  analyzing  the  user  requirements 
on  POLs  in  a two  fold  manner : 

A)  What  are  the  user  requirements  on  POLs  in  the 
sense  of  special  application  systems  (top  down 
approach) ? 


PBSCKDINO  F40K 
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B)  What  are  the  requirements  on  POLs  in  the  sense 
of  high  order  languages  which  enable  the  user  to 
program  individual  (prototype)  software  and  to 
construct  flexible  modules  (of  application  systems) 
which  are  reusable  in  classes  of  applications 
(bottom  up  approach)? 

The  second  approach  is  necessary  because  special 
application  systems  usually  don't  fit.  They  have  to 
be  adapted  or  extended  and  this  work  should  be  reduced 
by  doing  it  on  a high  level . 

3.  There  have  been  three  initial  presentations  and  a 
long  discussion  on  requirements  concerning  2 A)  and 

2 B)  during  the  last  meeting  at  Sept.  26-27,  1977.  The 
results  will  be  refined  and  extended  until  the  next 
meeting  on  January  11-12,  1978.  Then  POL-E  will  also 
discuss  special  application  systems  programmed  in 
realtime-FORTRAN  and  PEARL.  Generally  existing  high 
order  languages  will  be  checked  against  the  requirements. 

4.  The  aim  is  to  get  a future  oriented  list  of  require- 
ments which  can  be  given  to 

other  technical  committees , especially  LTPL  (short- 
term) , 
users, 

suppliers  (producers)  and 
standardization  groups  (long-term). 


CHAPTER  VI 


REPORT  OF  THE 

INTERFACES  AND  DATA  TRANSMISSION  COMMITTEE 


The  following  documents  are  included  here: 
1.  Summary  of  Activities,  TC5-C. 


2.  Report  of  TC5-E. 
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2)  Methods  and  procedures  will  be  developed  for  the  analysis  of  candidate 
systems  and  the  recording  of  the  resulting  data. 

3)  As  the  next  phase  of  its  work  WG6  intends  to  prepare  a draft 
standard. 

Affiliations 

Purdue  University 

Instrument  Society  of  America  through  Oata  Handling  and  Computations,  Chemical  and  Petroleum  Industries,  and  Automatic  Control  Divisions 
I nternat ional  Federation  for  information  Processing  as  Working  Group  WG5-4.  Common  and/or  Stand.n di/ed  Hardware  and  Software  Tech- 
niques of  T echnical  Committee,  TC-5,  Computer  Applications  in  Technology 
institute  of  Electrical  and  Electronic  Engineering,  Data  Acquisition  and  Control  Committee  of  the  Computer  Society,  and  Industrial  Control 
Committee  of  the  Industrial  Application  Society 
l nternationai  Federation  of  Automatic  Control,  Computer  Committee 
Nat  tonal  Research  Council  of  Canada,  Associate  Committee  of  Automat  ic  Control 

Commission  of  the  European  Communities  (CEC)  through  its  Directorate  General  foi  I ndustr  lal  and  I cchnoingical  Af fan  s 
Japan  Fiectronic  Industry  Development  Association  (JEIDA)  through  its  IPW  Japan  Committer* 
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Other  WG<i  Documents  (Appendix  U) 

Messrs.  Wood  and  Dorey  have  submitted  a recommended  terminology  for 
communication  networks  (WGO  (Wood-Dorey)2). 

Two  papers  by  Dr.  G.  Funk  compare  the  data  reliability  and  efficiency 
of  various  protocols  (WG6  (Funk)  2 and  3). 

IEC-TC66-WG3  (see  Appendix  HI) 

A report  was  received  from  Mr.  Dan  Loughry  on  the  proposed  objectives 
for  the  serial  extension  of  66  (Central  Office)  22,  which  is  essentially  the  IEEE 
4S8  bus.  All  members  are  urged  to  study  these  documents  in  detail  before  the 
next  meeting. 

Functional  Requirements  - Title 


The  meeting  agreed  with  the  proposal  that  an  improved  title  be  found. 
Wording  such  as  "Data  Highway  for  Distributed  Digital  Industrial  Process  Control 
Systems"  would  better  identify  the  contents  and  intent  of  the  document.  The  actual 
wording  of  the  title  was  left  to  WG6. 

Bit  and  Byte  Oriented  Protocols 

Because  of  the  wide  spread  adoption  of  HDLC  and  SDLC  in  North  America 
and  the  international  acceptance  of  HDLC,  TC5  feels  that  HDLC-like  protocols 
must  be  seriously  considered  for  distributed  industrial  process  control. 

The  work  of  Dr.  Funk  points  out  a source  of  error  in  bit  oriented  proto- 
cols. It  is  important  to  the  work  of  this  committee  that  the  significance  of  this 
error,  and  methods  to  minimize  it  be  examined.  To  this  end  the  meeting  passed 
the  following  motion: 

The  TC-5  Interfaces  and  Data  Transmission  Committee  of 
the  International  Purdue  Workshop  requests  the  assistance  of  the 
Purdue  University  in  evaluating  the  work  of  Dr.  G.  Funk  concerning 
data  transmission  reliability  presented  in  the  following  documents: 

1.  Comparison  of  data  reliability  and  efficiency  in  various 
standard  protocols  for  information  exchange  in  computer 
telecontrol  networks.  IEC/SC65A/WG6(Funk)2 

2.  Standard  reliability  requirements  for  data  transmission. 
IEC/SC65A  AVG6(Funk)3 
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The  work  assignment  of  the  Purdue  representative  will 
include  an  overseas  trip  to  Brown  Boveri  & Co.  Ltd.  in  Baden, 
Switzerland  (payment  to  be  solicited  from  P.M.C.)  to  meet 
with  Dr.  Funk. 

The  intent  or  the  work  effort  will  be  as  follows: 

1.  Determine  the  arithmetic  discipline  and  basic 
assumptions  used  to  formulate  the  conclusions. 

Be-state  these  assertions  in  lay  terms. 

2.  Determine  the  validity  of  the  discipline  and  assump- 
tions as  applied  to  industrial  communications.  De- 
termine the  order  of  magnitude  (translated  into 
potential  failure  of  communications  (time  period) 

of  the  reliability  conclusions. 

3.  Present  to  the  TC5  group  a paper  stating  in  lav 
terms  the  applicability  and  concerns  of  the  11DLC, 
bit-stuffing  protocol,  in  terms  of  potential  message 
failure  in  time  where  messages  are  bit-oriented 
and  where  message  are  byte-oriented. 

4.  Present  to  TC5  any  message  etv  oding  techniques 
for  the  1IDLC  protocol  which  would  yield  an  order 

of  magnitude  increase  in  reliability  of  communications. 

5.  Present  to  TC5  any  postulated  encoding  technique 
whose  analysis  yields  more  reliable  message  traffic 
stating  trade-offs  made  using  this  technique  against, 
for  example,  the  HDLC  protocol.  Specifically  include 
any  protocols  proposed  by  Dr.  Funk. 

6.  Present  to  TC5  a comparison  of  features  oT  the  HDLC 
protocol  (considered  from  a theoretical  communications 
viewpoint)  as  opposed  to  other  protocols  considered, 
viz:  fixed  word  format,  byte  format,  etc. 


It  was  further  agreed  that  this  motion  should  be  presented  to  the  full 
Workshop  for  a vote. 


(Chairman's  Note:  The  Workshop  voted  unanimously  to  support  this  motion.) 


Mr.  Harvey  Shepherd  agreed  to  form  a sub-committee  to  manage  the  work. 
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Clarilic  at  Ion 

During  the  course  of  the  meeting  it  became  evident  that  there  was  some 
uncertainty  as  to  which  level  in  an  industrial  computer  system  the  Committee  was 
addressing. 


Appendix  IV  contains  the  block  diagram  used  during  the  initial  discussions 
on  this  subject  by  the  Committee  in  l!)75.  It  was  agreed  at  that  time  that  the  rele- 
vant interface  is  the  one  labeled 

"a  10  - Derived  Channel”. 

A nalvsis  of  Candidate  Systems 

A sub-committee,  composed  of  Messrs  Barsamian,  Diefenderfer , Crowder 
and  Sanders,  was  formed  to  be  responsible  tor  the  preparation  and  continued  refine 
ment  of  a suitable  format  to  facilitate  the  analysis  of  candidate  systems  and  the 
comparison  of  alternate  implementations. 

Honeywell  TPC  2000  (see  Appendix  V) 

Mr.  Diefenderfer  gave  an  excellent  presentation  of  the  TDC  2000  system 
together  with  a comparison  on  the  format  of  the  Japanese  proposed  guideline. 

Fibre- Optics  Presentation  (see  Appendix  VI) 

Mr.  C.  Podlesny  of  the  Calileo  Electro-Optics  Corp.  discussed  the 
characteristics  and  performance  of  commercial  fibre-optic  cables. 

SD1.C  Protocol  Controller  (see  Appendix  VII) 

Mr.  John  Wipfli  of  Intel  Corp.  described  the  INTEL  8273  SDLC  protocol 
controller  chip. 

Future  Mission 

Many  members  have  now  responded  to  the  request  for  suggestions  ns  to 
the  future  direction,  objectives,  and  time  scale  of  the  Committee's  activity.  A 
summary  of  this  information  will  be  prepared  for  the  next  meeting. 


Workshop  Panel 

During  the  Workshop,  a panel  session  "The  Impact  of  New  Trends  in 
Hardware  on  Computer  System  Interfaces”  was  held.  Copies  of  the  presentations 
by  Tony  Deramo,  Chas.  Farmer,  and  Dan  Sre  are  included  in  Appendix  VIII. 


M1L-1553R 


Appendix  EX  contains  a copy  of  the  proposed  MIL- STD-  1553B  which  super- 
sedes MIL- STD- 1553 A . 

Candidate  Systems 


Members  are  urged  to  propose  and/or  solicit  implementations  for  analysis 
as  candidate  systems. 

Future  Work 

At  this  point  in  time,  with  WG6  assuming  the  job  of  editing  the  functional 
requirements,  the  Committee  can  concentrate  on  the  analysis  of  candidate  systems 
and  the  development  of  specifications. 

At  the  next  meeting,  agreement  should  be  reached  as  to  which  specific 
areas  of  the  functional  requirements  will  be  the  starting  point  for  the  preparation 
of  detailed  specifications. 

Next  Meeting 

The  next  meeting  will  be  held  January  12-13,  1978  at  IP.M  Corp. , Boca 
Raton.  Dr.  Sze  will  host  this  meeting.  He  has  arranged  for  a Series/1  Archi- 
tectural tutorial  for  the  afternoon  of  January  12  and  an  SDLC  tutorial  for  the 
morning  of  the  13th.  A plant  tour  will  also  be  scheduled. 


RWGrmf 


R.  \V.  C.ellie, 
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KARLSRUHE , D£N  23.l)./7  11,25  H 

FS.  NR.  Obi/)  / MO 

N.  E.  MALAGARD 1 S 
I R I A 

ROCQUENCOURT 

FRANCE 


RESPONDING  TO  YOUR  MESSAGE  OF  SEPTEMBER  0 HERE  IS  MY  SNORT 
REPORT  ON  TC  5 ACTIVITIES  AND  FUTURE  PLANS: 

THE  TC  5 WORK  IN  THE  LAST  YEAR  MAY  BE  TYPIFIED  AS  AN  EXTENSIVE 
DISCUSSION  OF  THE  COMMITTEES  DRAET  FOR  A SERIAL  LINE  SHARING 
SYSTEM  FOR  REAL  TIME  APPLICATIONS  (SIR).  THE  DISCUSSION  TOOK 
PLACE  WITHIN  TC  5 AS  WELL  AS  IN  INTERNATIONAL  STANDARDIZATION 
COMMITTEES.  IN  COMMENTS  AND  CRITICISMS  THE  INCOMPATIBILITY 
WITH  HDLC  AND  THE  LACK  OF  PROCEDURES  FOR  TRANSFERRING  BUS 
CONTROL  FUNCTIONS  FROM  ONE  STATION  TO  ANOTHER,  THE  SO-CALLED 
MASTER  TRANSFER,  WERE  POINTED  OUT  AS  DISADVANTAGES. 

THEREFORE  THE  5tH  SUBGROUP  MEETING  WAS  EXCLUSIVELY  HELD  TO 
INVESTIGATE  THE  APPLICABILITY  OF  HDLC  AND  5DLC  FOR  SIR.  AS 
FURTHER  CONSEQUENCE  THE  PRESENT  WORKING  PLAN  PROVIDES  THE 
IMPROVEMENT  OF  SIR  BY  MASTER  TRANSFER  CAPABILITIES  AND  ADDI- 
TIONAL BY  PROCEDURES  FOR  DIRECT  COMMUNICATION  BETWELN  ANY  TWO 
BUS  STATIONS  WITHOUT  INVOLVING  THE  PRESENT  BUS  MASTER  (CROSS 
COMMUNICATION).  APPROPRIATE  PROPOSALS  GENERATED  BY  COMMITTEE 
MEMBERS  FORM  THE  BASIS  FOR  THE  NEXT  TC  5 SUBGROUP  MEETINGS. 

THE  WORK  IS  SUPPORTED  BY  PRACTICAL  EXPERIENCES  GAINED  WITH 
PROTOTYPE  PDV-BUS  SYSTEMS  IN  GERMANY  WHICH  ARE  SIMILAR  WITH 
SIR. 

IT  IS  INTENDED  TO  PRESENT  THE  IMPROVED  SIR  DRAFT  AT  THE  NEXT 
ANNUAL  MEETING  OF  PE. 


H.  WALZE  / PDV 

GESELLSCHAFT  FUER  KERNFORSCHUNG  MBH 


C90109F 
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CHAPTER  VII 


REPORT  OF  THE 

MAN/MACHINE  COMMUNICATIONS  COMMITTEE 


The  following  documents  are  included  here: 

1.  Minutes  of  the  TC6-C  Meeting  of  October  3-6,  1977. 

2.  Annual  Report  1966-67,  TC6-E  (Revised). 

3.  Reasons  for  Implementing  and  Not  Implementing  Modern 
Man-Machine  Interface  Functions. 


jpRKCKDINQ  PAfl*  BUAMC 
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TC-6  MAN/MACHINE  COMMUNICATIONS 
INTERNATIONAL  MEETING  1977  MINUTES 


The  attendance  was  good  at  each  session.  The  American 
Committee  is  remaining  fairly  constant  with  about  15  working 
members . 

Four  main  items  were  put  on  our  work  schedule.  These 


were : 


1.  Finalization  of  Bibliography  Catagorization . 

2.  Device  Independent  Language  Specifications 


if  possible.  (WG  1) 

3.  Justification  for  MMIF.  (WG  2) 

4.  Updating  of  Guidelines  (WG  3) 

a)  With  Respect  to  PE  TC-6  work 
about  the  User  - Who  Is  It. 

b)  With  Respect  to  Microprocessors/ 

Microcomputers . 

It  was  decided  to  work  on  items  2 and  4 since  these  are 
interrelated . 

A list  of  some  35  items  or  tasks  that  could  be  performed 
at  a MMIF  was  prepared.  Another  list  of  users  and  definition 
of  the  user  was  prepared.  We  have  seven  defined  users.  It 
is  to  be  understood  that  there  may  be  more  than  one  level  of 
each  type  of  user. 

From  these  two  lists  a cross  reference  matrix  was  obtained. 
This  initial  effort  will  be  distributed  to  all  TC ' s for 
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ccmnnents,  additions  and  deletions. 

Discussions  concerning  our  liaison  with  other  groups  was 
reviewed.  We  are  inviting  groups  such  as  Human  Factor  Society 
members  to  join  us  at  Purdue.  Other  contacts  are  being  made 
and  reports  of  groups  such  as  the  IEEE  Nuclear  group  are  being 
collected  for  study. 

R.  Thompson  will  act  as  Sub-chairman  of  revisions  on  the 
Guidelines . 


R.  F.  Carroll 


The  Man-Machine  Communications  Committee  (TC6)  is  now 
composed  of  a fairly  stable  group  of  active  members  (10 
members  from  8 European  countries) . 

The  committee  has  found  that  information  about  Purdue 
Europe  and  the  activity  of  each  committee  to  the  users  of  its 
results  is  very  important.  A brochure  presenting  Purdue 
Europe  and  the  work  of  TC6  has  been  printed  and  is  now  being 
distributed  by  each  committee  member  on  a national  basis. 

The  work  on  a questionnaire  covering  the  field  of  "User 
interface  in  process  control  within  European  industries" 
has  been  finished.  A report  presenting  the  results  from  the 
analysis  of  the  collected  information  is  available.  Press 
release  will  be  sent  to  European  and  International  magazines 
for  a wider  distribution. 

Many  presentations  by  technical  committees  have  referred 
to  the  user  in  widely  differing  contexts.  To  clarify  this 
matter  TC6  has  produced  a working  paper  with  the  title 
"Towards  meeting  the  needs  of  the  user".  This  paper  has  been 
distributed  to  the  other  TC's  of  Purdue  Europe  for  further 
discussion  and  comments.  Based  on  feedback  from  the  commit- 
tees, we  shall  try  t.o  analyze  the  problem  somewhat  further  and 
present  the  results  in  form  of  a working  paper. 

The  committee  has  continued  its  work  on  establishing,  a 


general  guideline  for  the  design  of  Man-Machine  Communication 
(MMC)  Systems.  At  present  the  main  activity  is  directed 


towards  a way  of  influencing  the  design  procedure  more  than 


the  implementation.  This  work  contains  activities  such  as: 

Analysis  of  and  comments  of  the  US  Draft  Guide- 
line on  Design  of  Man-Machine  Interface  in  Process 
Control . 

Cooperative  work  with  the  US  TC6. 

Work  on  new  ideas  for  establishing  a framework  of 
a General  Guideline  for  MMC  in  Industrial  Computer 
Systems . 

Seek  for  financial  aid  from  CEC  and  other  organi- 
zations in  order  to  increase  the  activity  of 
establishing  such  a Guideline.  TC6 1 s scope  of  work 
is  too  large  to  be  covered  by  TC6  members  on  a 
voluntary  basis.  A working  paper  with  the  title 
"Automation  and  Man-Machine  Communications  - Aims 
and  Activities  of  TC6"  has  been  presented  to  the 
CREST  subcommittee  on  Informatics  of  the  Commission. 

Furthermore  plans  have  been  made  for  a workshop 
where  the  committee's  ideas  can  be  discussed  and 
commented  on  by  people  from  European  industry  and 
R&D  organizations  in  this  field.  A round-table 
discussion  on  MMC  will  be  organized  at  the  IFAC 
Congress  in  Helsinki,  June  1978  by  members  of  the 
committee. 

Some  time  ago  the  committee  started  work  on  collecting 
information  about  European  organizations  working  in  the  field 
of  Automation  - MMC  - Human  Factors  (Ergonomics) . Draft 
paper  available.  In  due  time  this  information  will  be  avail- 
able in  form  of  a survey  paper.  A liaison  with  the  ISO/WG 
on  Standardization  in  Ergonomics  will  be  established  in  the 
near  future. 

Last  but  not  least,  the  committee  members  have  frequently 
presented  the  aims  and  work  of  Purdue  Europe  and  especially 
that  of  TC6  in  their  respective  countries. 


f 
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From  our  last  TC6  Meeting: 

The  creation  of  Guidelines  on  MMC  is  closely  related 
to  Guidelines  for  Systems  Design,  e.g.,  one  cannot 
disconnect  these  two  activities  at  any  time  during 
the  design  phase. 

We  have  also  found  it  necessary  to  work  more  with 
glossary  - the  meaning  of  words,  such  as:  jobs, 
tasks,  procedures,  activities,  functions  - is  not 
very  clear.  We  therefore  have  to  define  some  of 
them  our  way.  A correspondence  with  software 
people's  use  of  them  is  not  clearly  seen. 

R.  Thompson  has  asked  us  to  look  into  the  possi- 
bilities of  judging  utilization  of  Guidelines  for 
contracting  purposes. 
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REASONS  FOR  IMPLEMENTING  AND  NOT  IMPLEMENTING 
MODERN  MAN -MACHINE  INTERFACE  FUNCTIONS 

REASONS  FOR  IMPLEMENTING  MODERN  MMIF 

1.  Operations  manpower  reduction  (greater  no.  of  loops 
handled) . 

2.  Reduces  operator  error  (saves  process  downtime  and 
improves  product  quality). 

3.  Reduces  overall  size  of  control  room. 

4.  Reduces  maintenance  (fewer  controls  & indicators). 

5.  More  adaptable  to  process  growth  and  charge. 

6.  Implementations  using  modern  hardware  are  more  reliable. 

7.  Availability  of  the  MMIF  will  be  as  high  using  modern 
equipment  and  architectures  as  older  designs. 

8.  Job  enrichment  for  the  operator. 

9.  Eases  operator  training  (new  operators  especially). 

10.  Lower  installed  cost  for  MMIF  (especially  for  larger 
systems  - eq.  cabeling) . 

11.  May  be  replacing  non  replaceable  instrumentation  (not 
making  anymore) . 

12.  Process  optimization  may  be  lesser. 


13.  Better  managerial  capability. 

14.  Compliance  with  Government  Regulations. 


*Wh. 
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REASONS  OFFERED  FOR  NOT  IMPLEMENT IMP  MODERN  MM IF 


Existing  (experienced,  lower  level)  people  may  not  be 
capable  of  being  used  to  design  and  implement  the  MMIF 
for  a new  system.  They  feel  more  secure  with  the 
existing  design  and  implementation. 

Existing  technology  can  be  used.  This  offers  less  risk 
and  is  more  available  and  better  understood. 

Less  design  time  and  money  are  required  by  retaining 
the  existing  design. 

The  operations  and  maintenance  people  and  practices 
may  be  different  with  a new  design. 


Misunderstandings  of: 

5-1  Cost  of  new  MMIF 

5-2  Area  of  impact  - will  it  be  overkill?,  too 
elegant? 

5-3  Effects  on  operating  people  and  their  jobs 
5-4  Not  directly  related  to  profits  (the  "business" 
of  the  corporation) 

New  MMIF  frequently  increases  the  degree  of  abstraction 
of  the  process. 

New  MMIF  frequently  requires  a more  sophisticated  CPL 
system  than  would  otherwise  be  required. 

Less  reliable  due  to  common  hardware. 


9.  Government  Regulations. 
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REASONS  OFFERED  FOR  NOT  IMPLEMENTING  MODERN  MMIF  (Cont.) 


10.  Possible  Union/Operator  Concern/Job  Dislocations 


11.  Environment. 


COSTS  INCURRED  BY  MODERN  MMIF 


Additional  design  costs 
training 
staffing 


contractors 


2.  Additional  maintenance  costs 
None  - probably  less 


3.  Additional  training  costs 
maintenance  people 


4.  Additional  hardware  and  software  costs 
CPU  system  is  more  complex 
risk  of  new  technology 


These  cost  items  must  be  balanced  against  savings  in 
operations  manpower,  (re*.,  ,'ed  operator  error,  and  smaller 
control  room) . 
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CHAPTER  VIII 


REPORTS  OF  THE  SYSTEMS  RELIABILITY 
SAFETY  AND  SECURITY  COMMITTEE 


The  following  documents  are  included  here: 

1.  Report  of  the  Systems  Reliability,  Safety  and  Security 
Committee . 

2.  Minutes,  September  29,  1977  Meeting,  TC-7,  Purdue  Europe. 

3.  Brochure,  TC7-A. 


jt 
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INTERNATIONAL  PURDUE  WORKSHOP  ON 
INDUSTRIAL  COMPUTER  SYSTEMS 


PURDUE  LABORATORY  FOR 
APPLIED  INDUSTRIAL  CONTROL 
102  Michael  Golden 
Purdue  University 

West  Lafayette,  Indiana  4/90  7,  USA 
317/494  842b 


Please  reply  to 


COMMITTEE  TC-7 

System  Reliability,  Safety  and  Security 
Purdue  University 
West  Lafayette,  Indiana,  USA 
Oct.  3 - 6,  1977 

[1 

' 


Committee  Chairman  - R.  W.  Yunker 

Participating  Members:  William  V.  Brown 

Dr.  Rudolph  Kanokovsky 
Purdue  Europe 
Ichiro  Ido  - Purdue/Japan 


PRscsmaa  j*qk 


Affiliations: 

Purdue  University 

instrument  Society  of  America  through  Data  Handling  and  Computations,  Chemical  and  Petroleum  Industries,  and  Automatic  Control  Divisions 
imtmii.unii  Federations  for  information  Process. ng  as  Working  Group.  WG5-4.  Common  ana/or  Standardised  Hardware  and  Software  Tech- 
mques  of  Technical  Committee,  TC-5,  Computer  Applications  in  Technology 
Institute  of  Electrical  and  Electronic  Engineering,  Data  Acquisition  and  Control  Committee  of  the  Computer  Society,  and  Industiial  Control 
Committee  of  the  industrial  Applications  Society 
international  Federation  of  Automatic  Control,  Computer  Committee 

Commission  of  the  European  Communities  (CEC)  through  its  Directorate-General  for  Industrial  and  Technological  Affairs 
Japan  Electronic  industry  Development  Association  (JEIDA)  through  its  IPW  Japan  Committee 


W 


Presentations  were  made  on  the  progress  being  made  in  the  respective 
areas  toward  the  individual  goals. 


Purdue  - Europe  countinues  its  very  active  program  under  the  direction  of 
Professor  Lauber.  Dr.  Rudolph  Kanokovsky  representing  Professor  Lauber  sub- 
mitted a booklet  of  12  papers  published  by  the  committee  in  the  field  of  Safety 
and  Security;  together  with  a bibliography  of  all  papers  to  date.  It  is  well 
to  note  that  this  prolific  group  has  over  129  papers  published  at  this  time. 

All  in  English  I might  add. 

They  have  approximately  a 41  member  group  divided  into  24  active  partici- 
pants member  and  17  corresponding  members.  To  be  elected  a full  member  of  the 
conmittee  requires  partici pation  in  the  3 or  4 meetings  held  during  the  year 
in  Europe  and  the  presentation  of  one  or  more  papers. 

As  they  are  a large  committee  they  have  found  it  expeditious  to  organize 
into  5 sub-groups.  These  are: 

1)  Terms  & Definitions 

2)  Project  Management 

3)  Hardware 

4)  Software 

5)  Documentation 


Their  committee  emphasizes  Safety  of  Computer  Systems  in  their  programs. 

This  results  somewhat  (as  to  be  expected)  from  the  backgrounds  of  their  members, 
being  largely  Nuclear  and  Railroads,  together  with  Universities  associated  with 
programs  in  these  activities. 

Their  present  area  of  emphasis  is  in  developing  Software  Guidelines  & 
Statistical  testing.  In  addition  they  have  expanded  their  terms  and  definitions, 
adding  30  - 40  New  terms. 

Of  particular  interest  to  the  committee  are  the  papers  on  software  reliability 
and  guidelines  for  documentation.  The  International  committee  is  particularly 
indebted  to  their  committee  for  their  pioneer  work  in  publishing  in  these  areas. 

In  the  area  of  mutual  interaction  they  have  requested  a bibliography  of 
U.S.  work  in  the  field  of  software  reliability.  Which  the  U.S.  committee  will 
supply. 

They  have  also  requested  an  evaluation  of  their  most  recent  glossary  terms. 
These  terms  will  appear  in  the  minutes  and  I would  like  to  ask  that  each  of  the 
TC  committees  review  these  terms  and  provide  comnents.  I suggest  that  the  most 
expedient  method  for  doinq  this  would  be  throuqh  the  TC-7  committee. 

Purdue  - Japan's  proqram  was  presented  by  their  chairman  Mr.  Ichiro  Ido. 

Their  committee  consists  of  16  members  and  a chairman,  Mr.  Ido.  Each 
member  representing  a different  company.  The  representation  ranges  from 
Electrical,  Electronic  and  Instrumentation  ( and  a Photo  Film  Company). 

As  a result  they  have  a very  broad  based  industrial  participation. 
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The  Committee  acts  as  a sub-committee  of  JEIDA  (Japanese  Electrical 
Industry  Development  Association).  As  a result  it  is  to  be  expected  that 
their  recownendations  will  not  be  taken  lightly  by  Japanese  Industry. 

They  are  one  of  5 committees  in  JEIDA.  The  others  being  Standards, 
Software,  Hardware  and  General  Survey. 

The  committee  is  divided  into  two  working  groups;  Installation  and 
Maintenance.  Their  strategy  being  that  the  field  of  Reliability,  Safety  and 
Security  is  very  large  and  that  they  can  best  attack  the  problem  initially  in 
these  two  areas. 

Mr.  Ido  presented  an  extensive  paper,  from  the  committee  representing 
the  work  to  date  on  "Proposed  Guidelines  for  Environmental  Standards  for 
Industrial  Computers."  The  paper  encompasses  Classification  of  Environments; 
Temperature,  Humidity,  Power,  Noise,  Vibrations,  Dust  and  Corosive  Gas 
provisions  and  influence;  and  finally  a discussion  on  Computer  Security.  As 
such  it  is  a very  complete  work  and  adds  greatly  to  the  mutual  efforts  of  the 
other  committees.  It  represented  the  work  of  a committee  under  the  direction 
of  Mr.  K.  Fuijta. 


If  these  guidelines  are  accepted  they  will  submit  a second  set  on  System 
Maintenance. 

Mr.  Ido  has  requested  that  similar  efforts  be  started  in  the  U.S.  and 
European  committees  so  that  realistic  international  guidelines  might  be 
generated. 

The  general  strategy  of  the  Japanese  Committee  is  to  divide  the  scope  into 
4 areas.  These  are: 

1 . System  Design 

2.  Operations 

3.  Installation 

4.  Maintenance 

Their  committee  schedule  indicates  that  Installation  and  Maintenance 
Guidelines  will  be  concluded  in  1978  and  the  Reliability  area  of  System  Design 
should  be  finished  in  1978.  This  includes  such  things  as  definitions  for 
MTBF  and  MTTR  for  industrial  distributed  control  specifications.  In  addition, 
works  on  "Standardization  of  Hardware  Proof  Testing"  and  "Standardization  of 
Documentation  for  Requirement  Specification"  are  in  the  process  by  the  standards 
committee  and  are  being  published. 

The  U.S.  committee's  progress  to  date  was  presented  by  Mr.  Yunker.  In 
essence,  it  said  that  after  last  years  International  Meeting  from  which 
Strategy,  Scope  and  Objectives  were  developed,  little  progress  has  been  made 
because  of  lack  of  participating  members.  While  several  efforts  have  been 
initiated  to  improve  participation  they  have  not  as  yet  been  successful. 

Chief  among  these  is  a brochure,  modeled  after  the  Immparently  successful 
TC-7  of  Purdue  Europe  which  has  jsut  recently  been  sent  out.  Suggestions 
and  comments  were  solicited  from  the  committee  members. 
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Mr.  William  Brown  of  the  Celanese  Corporation,  the  third  committee 
member  made  several  valuable  suggestions  on  personnel  to  be  contacted  as 
potential  member  candidates. 

After  the  individual  conmittee  reports,  we  attempted  to  further  clarify 
individual  company  and  committee  goals.  Discussion  relating  to  safety  versus 
reliability,  redundant  systems,  "How  do  you  maintain  a safe-reliable  system 
given  the  possible  untested  probalistic  pertabations  and  combinations  in  a 
computer  operating  system,  coupled  with  the  same  order  of  probabilities  in 
an  application  system."  "How  do  you  handle  reliability  in  distributed  systems, 
and  how  do  the  particular  countries  report  reliability,  and  some  of  the 
problems  involved."  All  these  discussions  contributed  to  each  of  our  under- 
standings of  the  particular  problem  and  also  clarified  our  definitions.  This 
in  spite  of  the  distinct  disadvantage  our  European  and  Japanese  counter  parts 
had  in  communicating  there  exact  thinking  in  our  native  tongue. 

To  Summarize: 

As  a result  of  this  meeting: 

The  U.S.  TC  committee  will  continue  and  intensify  its  efforts  to  attract 
more  members.  Along  this  line,  we  tentatively  plan  to  invite  major  industry 
process  control  managers  to  participate.  We  would  hope  that  present  attendees 
to  the  conference  will  make  appropriate  people  in  their  respective  organizations 
aware  of  this  and  they  can.  if  interested,  contact:  R.  W.  Yunker 

% PPG  Industries 
One  Gateway  Center 
Pittsburgh,  PA  15222 
(412)  434-3377 

Together  with  Mr.  Brown  we  believe  we  can  in  this  way  form  the  nucleous 
of  a group  which  will  encourage  more  U.S.  participation. 

We  will  supply  TC-7  Europe  with  a U.S.  bibliography  on  "Software  Re- 
liability." Also  consideration  of  the  Japanese  guidelines  for  Environmental 
standards  will  be  made  with  general  U.S.  standards. 

Finally,  we  hope  that  we  can  continue  to  have  the  excellent  interchange 
and  information  discussions  that  characterized  our  Committee's  meeting  this 

year'  /?  u 

R.  W.  Yunker 
Chairman  TC-7 

RWY : kmd 
Enclosure 
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Full  Committee  Meeting,  Sept.,  29. 


1 .  Agenda 

The  agenda  was  approved. 


2 .  Minutes 

The  minutes  from  the  Vienna  meeting  (WP  117)  were  approved, 
as  far  as  they  were  available.  It  was  stated,  that  the 
minutes  of  the  Project  Management  and  Terms  and  Definitions 
subgroups  were  missing.  They  should  be  added  to  WP  117. 


3 .  Member  List 

The  following  changes  took  place: 


Dr.  Drtil 
Mr.  Ellison 
Prof.  Cortes 
Mr.  Reinshagen 
Dr.  Scotland 
Mr.  Dahll 
Mr . Daoud 
Mr.  Hcdin 
Mr.  Heiner 
Mr.  Fangmeyer 


replaced  by  Mr.  Blaas 
corresponding  member 

tl  H 

II  II 


•I 


II 


member 

deleted 

deleted 

member 

corresponding  member 


Mr.  Engler  and  Dr.  Konakowsky  stay  as  members.  Changes  of 
address  or  telephone  numbers  at  Mr.  Gayen,  Dr.  Gcnser , 

Dr.  Vaid,  Mr.  Dahll. 

In  the  future  one  should  try  to  find  a procedure  to  handle 
the  member  list  more  quickly. 


■rw 


! 


4 . EC  and  Purdue  Europe 

Mr.  Thompson,  an  ancient  TC  7 member,  is  now  the  EC  secretary, 
who  is  responsible  for  Purdue  Europe  activities,  since 
I)r.  Diettrich  changed  to  another  department . He  gave  a 
presentation  on  the  different  groups  and  problems  between 
the  EC  and  the  European  Purdue  Workshop.  (See  figure) . 

Important  decisions  are  made  by  the  Council  of  Ministers. 
This  Council  consults  the  EC  official  bodies,  where  DG  3, 
to  which  Mr.  Thompson  belongs,  is  one.  Should  any  projects 
been  funded,  DG  3 would  supervise  them.  So  far  TC  3 has 
applied  for  getting  EC  support.  Up  to  now  however  nothing 
has  been  decided.  It  is  improbable,  that  anything  could 
start  in  1978. 

In  addition  to  DG  3 the  Council  of  Ministers  consults  the 
Working  Group  on  Standards.  This  group  is  complementary 
to  the  national  standardization  bodies.  It  has  been  founded 
in  anticipation  to  a need.  The  16  members  have  been 
appointed  by  the  governments.  Standards  in  informatics  are 
planned.  Up  to  now,  no  scedule  of  working  exists.  The 
commission  normally  does,  what  the  WC.S  advises. 

The  individual  TCs  of  the  European  Purdue  Workshop  fit 
more  or  less  into  the  standardization  activities.  TC  5 e.g. 
can  help  another  interfacing  committee.  In  this  case  the 
EC  will  pay  for  travelling  and  other  costs  of  interaction. 

TC  6's  aims  can  not  so  easily  be  subsumed  under 
standardization.  The  work  of  TC  1 however  fits  very  good. 

Concerning  v/orld  wide  standardization  it  is  necessary  to 
influence  the  national  standards  bodies,  in  order  to  get 
their  support  in  the  ISO. 
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If  TC  7 wants  some  funding  from  the  EC,  the  opinion  of  the 
CREST  committee  is  important.  This  committee  should  be 
influenced.  Since  however  many  sides  apply  for  money  from 
the  EC,  one  should  only  take  into  account  a small  study, 
achieving  one  particular  goal.  The  EC  so  far  did  not  give 
special  attendence  to  the  fact,  that  work  on  Safety  and 
Security  has  legal  aspects  as  well  as  technical  ones. 

According  to  the  EC's  opinion  the  EPW  should  help  to  use 
European  standards  and  thereby  be  complementary  to  the 
WGS . To  get  some  reasonable  results  a lot  of  volontary 
work  will  bo  necessary. 

Mr.  Thompson  is  interested  in  TC  7's  work.  He  intends  to 
come  to  each  meeting.  In  order  to  keep  informed,  what  the 
committee  does,  he  will  collect  the  working  papers.  His 
advice  is,  TC  7 should  find  and  keep  close  contact  to 
CREST  and  WGS  on  the  one  side  and  to  the  national  stan- 
dardization bodies  on  the  other. 

5.  I FAC 

The  panel  discussion  proposed  by  TC  7 was  accepted. 

6.  Report  on  state  of  Safety  Methods  in  the  US 

Dr.  Cooper  gave  a presentation  of  his  impressions  from 
the  conference  in  Pittsburgh  in  the  software  subgroup. 

They  are  written  down  in  WP  130,  which  is  available  for 
all  members. 

Then  Dr.  Cooper  presented  his  paper  of  the  Pittsburgh 
Conference,  entitled  "Some  Reliability  Aspects  of  the 
Design  of  Computer  Based  Safety  Systems".  This  paper 
was  distributed  as  WP  no.  125.  A report  on  that  subject 


% 
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will  be  available  later.  It  also  will  be  distributed  to 
the  committee.  The  discussion  centered  on  the  reliability 
figures,  which  the  system  should  meet  and  on  the  question 
whether  in  addition  to  a formal  specification  an  informal 
one  should  be  required. 

7 . Next  Meeting 

The  next  meeting  will  be  in  Brussels,  Jan.  18.-20.,  1978. 

8 . Miscel. laneous 

Mr.  Aitken  asked  for  probability  models  for  software. 
Messrs.  Scotland  and  Cortes  presented  themselves  to  the 
committee . 


W.  Ehrenberger 
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Full  Committee  Meeting,  Sept.  30. 


1 . Minutes 

Minutes  should  be  sent  to  Mr.  Taylor  in  typed  form,  for 
distribution. 

1 

| 

2 . Next  Topics 

The  committee  is  interested  to  get  concerned  with 
specification  methods.  During  the  next  meeting  a 
tutorial  should  be  hold.  Mr.  Levene  volonteered  to 
invite  privately  some  specialists  for  presentation.  The 
official  invitation  should  be  made  by  Prof.  Lauber.  The 
presentations  should  be  fareseen  for  the  whole  commit  tee 
on  the  afternoon  of  the  middle  day. 

3 . Suggestion 

During  TC7  meetings  more  time  should  be  spent  for  sub- 
group sessions. 

4 . Subgroup  Meetings 

The  individual  subgroups  reported  from  their  work.  (See 
subgroup  minutes) . 

W.  Ehrenberger 


L I 


. A 
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Minutes  of  Documentation  Subgroup  29.9.77 
Matters  arising  from  previous  meeting 

1.  Action  of  Mr.  Sehlcsingcr  - lie  now  hopes  to  complete  his  paper  for  next 
meet  ing. 

2.  Revision  to  FIPS  38  (see  Paper  i 18):  Development  (Management)  and 
Technical  description  aspects  should  be  separated. 

3.  Documentation  sub-group  will  concern  itself  in  detail  in  Systems  Requirements 
and  Descriptions.  Part  5 is  to  be  the  responsibility  of  the  Project  Management 
Subgroup. 

4.  It  was  agreed  that  "ancilliaries"  (Part  7),  could  be  called  "Associated  Equip- 
ment and  Software". 

5.  The  boundary  definition  is  to  be  more  clearly  defined  by  the  System 
Requirements  working  party. 

6.  Action  to  contact  L.  Goodstein  is  on  R.  Taylor. 

7.  4th  para,  page  3 of  previous  Minutes  is  satisfactory,  therefore  1st  para,  is  to 
be  deleted. 

8.  Pre- development  studies  and  analyses  should  be  included  in  Part  4 (Tei  h. 
Support  Documentation). 

9.  Correction  to  p.  4:  Part  3 working  party  to  be  entitled  "System  Description". 

10.  The  Sub-group  then  split  into  the  following  parties: 

System  Requirements  (Part  2) 

H.  Fangmeyer 
U.  Voges 
G.  Winter 
W.  Grau wilier 
B.  Sterner 

Syste m De s cripiton  (Pa vt  3 ) 

A.  Lcvcnc 
K.  Scotland 
S.  Bologna 
W.  Hockey 
A.  Costoa 
G.  Da  till 
S.  Vaid 
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Technic.il  Support  Docuiaont.il ion  (Pact  4) 

R.  Gen  Me x' 

P.  Sj  cilia 
W.  Ehrenberger 

11.  'Ihe  System  Description  working  party  concentrated  on  aspects  of  the  system 
level  documentation,  with  five  sub -sections: 


i) 

Overview 

ii) 

Subsystems  R Interfaces 

iii) 

Descripiion  of  implementation  of 

required  function 

iv) 

Overall  management  of  systems: 
re-configuration  of  system. 

configuration  & 

v) 

Maintenance  policy. 

12.  The  working  party  agreed  to  consider  in  detail  the  points  raised  in  TOSS  113 
within  the  structure  of  1 CSS  118. 

13.  Action  on  Mr.  Contes  to  prepare  content  for  hardware  system  description, 
other  members  to  prepare  content  of  software  system  description. 

14.  Dr.  Ehrenberger  agreed  that  the  Technical  Support  Documentation  Working 
Party  would  consider  the  economic  aspects  of  the  provision  of  documentation 
for  a project. 


. 
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Minutes  of  the  Software  Subgroup  Meeting,  September  28, 


Present : 
Ga  jen 
S joli.n 
Heiner 


Levene 

Cooper 

Grauwiller 


Vaid 

Fangmcyer 

Voges 


Dahl  1 

Bologna 

Ehrenberger 


1 . Minutes  last  Meeting 

The  minutes  are  included  in  WP  117.  They  were  accepted 
without  any  comments. 

2.  Report  from  Pittsburgh  Conference  on  Software  Reliability 

Jilv  1977 

Dr.  Cooper  presented  working  paper  no.  130.  His  major 
impression  was , that  concerning  software  reliability  in 
nuclear  power  plants,  European  knowledge  is  not  inferior 
to  US. 

3 . Sys tematic  Testing 
3.1  Sadat 

Mr.  Voges  presented  working  paper  no.  121,  which  describes 
a system  analysing  modules  of  FORTRAN  programs. 

During  the  discussion  the  following  points  were  stated: 
Presently  a module  to  be  analyzed  can  be  up  to  400 
statements  long.  If  the  number  of  iterations  of  a loop 
is  unknown,  2 or  5 repetions  arc  investigated,  if  no 
other  requirement  is  explicitly  given. 

Subroutines  are  considered  as  new  modules.  They  arc  there- 
fore analyzed  separately.  The  analyzer  puts  no  require- 
ments on  the  structure  of  the  analysis  object  and  does 
not  chock  whether  structuring  rules  have  been  fulfilled. 


w 


The  system  has  been  finished  since  one  month.  4 to  5 man 
years  effort  have  been  Involved,  mainly  from  students.  It 
is  programmed  in  Phi,  runs  on  an  IBM  370/1 G8. 


Now  a comparison  with  the  american  system  ItXVP  from 
General  Research  is  carried  out. 

3.2  Program  Analyzer  of  Taylor 
and  Bologna 

Mr.  Taylor  and  Mr.  Bologna  have  designed  and  implemented 
a program  analyzer  in  LTSP.  It  is  designed  for  analyzing 
programs  written  in  IFTRAN.  It  runs  on  a Burrough  B6700 
in  Rise  and  on  PDF  11  in  Cassaceia.  Due  to  memory  problems 
only  programs  with  about  200  executable  paths  can  be 
analyzed  at  the  moment.  Loops  are  investigated  inter- 
actively with  the  programmer,  who  must  indicate  whether 
an  additional  repetition  is  wanted.  The  analyzer  derives 
automaticly  path  predicates.  An  additional  program 
simplifies  them.  Unexecutable  paths  are  identified.  Out 
of  the  large  number  of  executable  ones,  the  relevant 
paths  are  selected  for  further  investigation. 

An  example  shall  be  given  during  the  next  meeting.  A 
working  paper  is  planned. 

The  system  is  used  to  analyze  the  protection  programs  of 
the  TAPIRO  reactor  from  CNEN. 

3.3  General 

Mr.  Voges ' system  found  some  inexeeutablc  paths  in  one 
analyzed  program.  The  analyzer  of  Taylor/Bologna  so  far 
did  not  detect  errors. 


4 . Software  Specification Methods 

Mr.  Ehrcnberger  presented  working  paper  no.  123.  A short 
discussion  was  devoted  to  the  question,  whether  decision 
tables  or  logic  diagrams  were  more  suitable  to  specify 
reactor  protection  functions. 

5 . Definition  of  Software  Reliability 

It  was  discussed,  whether  the  term  "reliability"  was 
suitable  for  software  in  the  form  as  defined  in  the. 

Terms  and  Definitions  paper  of  the  TC.  No  conclusion 
was  found. 


W.  Ehrenbergei 
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Terms  and  Definitions  Subgroup 


Minutes  of  the  meeting  in  Brussel  on  29th  and  3oth  September  1977 


1.  Present  were:  Mr.  Aitken 
Dr.  Frey 
Mr.  Gayen 
Mr.  Heiner 
Mr.  Hendry 
Mr.  Piintzner 
Mr.  Schuller 
Dr.  Schwier 
Dr.  Wobig 


2.  The  minutes  of  the  previous  meeting  in  Vienna  were  approved. 

3.  A proposal  from  Mr.  Voges  and  Mr.  Fanymeyer  concerning  the  definition 
of  the  term  reliability  was  discussed.  The  t & cl  members  didn't  see 
any  reason  to  change  the  definition  theugh  it  is  not  from  our  TC  but 
appl icable  for  us. 

Mr.  Heiner  proposed  to  define  the  term  danger.  A special  definition 
is  not  necessary,  because  the  technical  use  is  in  accordance  with  the 
dictionary. 

4.  Possible  classification  systems  for  the  glossary  of  terms  and  definitions 
were  discussed.  The  t & d agreed  on  a classification  in  alphabetical 
order.  In  addition  one  could  try  to  show  the  relationship  between  the 
terms  in  a tree  set  or  symbolic  type  of  presentation;  Dr.  Frey, 

Mr.  Hendry  and  Mr.  Schuller  volunteered  to  do  so  until  the  next  meeting. 

5.  A proposal  for  a final  subgroup  paper  was  discussed  and  will  be 
distributed  at  the  next  meeting  in  January  I97G.  This  paper  shall 
contain  four  columns  as  shown  below 


term 

1 

definition 

source 

document 

remarks 

j 

All  terms  will  be  listed  up  in  an  alphabetical  order  and  the 
column  remarks  will  contain  cross  references  if  necessary.  We 
looked  over  the  terms  in  section  1 and  2,  discussing  which  purls 
were  definitions  and  which  remarks.  Ihe  result  can  be  seen  from 
paper  no  132.  The  titel  of  paper  no  132  shall  be 

Glossary  of  Terms  and  Definitions 
related  to  the  safety  of  industrial 
computer  systems 

6.  The  definitions  of  the  terms  in  section  3 were  discussed  and  moved 
up  into  section  2.  These  terms  were:  voter,  decision  logic,  indepen- 
dent, standard,  verification,  prove,  validate.  The  results  will  In.- 
given  in  the  updated  paper  no  126.  One  will  find  some  explanations 

given  by  Mr.  Hendry  in  the  end  of  these  minutes. 

7.  The  terms  in  section  4 were  defined  and  moved  up  into  section  3 for 
further  descussion.  On  the  whole  we  agreed  on  the  definilons  given 
by  Mr.  Hend»y.  The  terms  considered  were:  safety  report,  safety 
audit,  demonstrate,  regulations,  dependability,  threat,  r out  of  n 
structure, 

f>.  explanation  given  by  Mr.  Hendry: 

We  wish  to  distinguish  between  tiic  verification,  proving  and  val idation 
of  systems,  software  etc.  Wo  can  identify  a number  of  differences: 

a)  Verification  is  the  lowest,  level  of  testing,  and  is  intended  lo 

show  that  the  item  works  correctly  with  the  input,  data  and  conditions 
used  in  the  test.  One  or  more  sets  of  test  conditions  may  bo  used, 
but  the  test  does  not  show  anything  outside  those  conditions. 


5 
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b)  Proof  shows  that  the  item  (or  part  of  an  item)  will  work  for 
all  relevant  input  data  and  conditions.  A substantial 
proportion  of  argument  or  analysis  is  implied,  although  veri- 
fication may  be  used  to  support  the  analysis. 

c)  Validation  shows,  in  addition  to  proof,  that  the  argument  or 
analysis  is  valid  under  all  reasonable  conditions  and  is  usually 
intended  to  give  confidence  in  the  proof  or  item  under  test. 

Hence,  a customer  acceptance  or  now  product  release  is  likely 
to  require  val idation.  Software  validation  usually  involves 
soak  testing,  testing  under  severe  conditions,  with  as  many 
interactions  as  possible  ••  "hammering"  the  system. 

■ 

Gayen  19.  10.  1977 


■ 
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Technical  Committee 
“Reliability,  Safety  and  Security” 

of  the 

International  Purdue  Workshop 
on  Industrial  Computer  Systems 
American  Regional  Organization 
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What  is  the  International  Purdue  Workshop  on  Industrial  Computer 
Systems?  (IPW) 

Founded 

1969  by  Prof  T J Williams  at  Purdue  University.  Lafayette,  Indiana,  USA 
Objectives 

To  make  the  definition,  justification,  hardware  and  software  design,  procurement,  programming 
installation,  commissioning,  operation  and  maintenance  of  industrial  computer  systems  more  efficient  and 
economical  through  education,  the  organization  and  interchange  of  information,  and  the  development  of 
standards  and  or  guidelines  on  an  International  basis 

Sponsors 

Purdue  University 
Instrument  Society  of  America 
International  Federation  for  Information  Processing 
Commission  of  the  European  Communities  (CEC) 

Japan  Electronic  Industry  Development  Association  (JEIDA) 

National  Research  Council  of  Canada 

Affiliations 

Institute  of  Electrical  and  Electronic  Engineering 
International  Federation  of  Automatic  Control 

Organization 

There  are  regional  branches  in  America,  Japan  and  Europe 

The  American  branch  comprises  the  following  Technical  Committees 

TCI  FORTRAN  Committee 

TC2  Industrial  BASIC  Committee 

TC3  Long  Term  Procedural  Languages  Committee 

TC4  Problem  Oriented  Languages  Committee 

TC5  Interface  and  Data  Transmission  Committee 

TC6  Man  Machine  Communications  Committee 

TC7  System  Reliability,  Safety,  and  Security  Committee 

TC8  Real-Time  Operating  Systems  Committee 

TC9  Glossary  Committee 


What  is  TC7  Concerned  With? 

TC7  is  concerned  with  Reliability,  i.e  . to  establish  procedures  and  practices  for  designing  and  operating 
computer  systems  reliably  and  with  properly  documented  performance 

TC7  is  concerned  with  Safety,  i.e.,  to  safeguard  human  well  being,  the  environment  and  property  against 
hazards  arising  from  internal  failure  in  computer  control  systems 

TC7  is  concerned  with  Security,  i.e..  to  establish  safeguard  practices  and  procedures  to  prevent  deliberate 
or  inadvertent  computer  operational  failures 


What  do  the  Programs  in  TC7  Deal  With? 

— exchange  of  experiences  and  ideas 
collection  and  evaluation  of  strategies 

— establishing  a catalog  of  proven  schemes 

proposing  to  international  standards  bodies  principles,  procedures,  and  guidelines 

defining  a list  of  terms  and  definitions  to  establish  clear  communication  between  professionals 


Who  can  Benefit  from  TC7  Participation? 

— industrial  users 

— national  authorities 

— research  laboratories 

universities  engaged  in  work  on  industrial  processes,  nuclear  power  plants,  railways,  and  aircraft  where 
reliability,  safety  and  security  standards  with  computer  systems  are  involved 


How  does  the  TC  "System  Reliability,  Safety  and  Security"  Interact  with 
other  Organizations? 

TC7  cooperates  with  and  participates  in  |oint  seminars  with 

the  European  and  Japanese  Technical  Committees  dealing  with  reliability,  safety  and  security 
the  sponsors  of  the  Purdue  Workshop 

TC7  through  the  Workshop  maintains  liaison  with 
the  American  National  Standards  Institute  (ANSI) 
the  American  Institute  of  Electrical  and  Electronic  Engineers  (AIEEE) 

U S Energy  Research  and  Development  Administration 
U S Nuclear  Instrument  Module  Committee 

What  Results  will  be  Produced  by  the  TC  "System  Reliability,  Safety  and 
Security?" 

The  results  will  be  contained  in  two  types  of  papers 

working  papers  produced  in  written  communication  to  the  committee  or  technical  |ournals.  generated 
at  the  request  of  the  committee  or  by  the  members 

guidelines  official  recommendations  to  standardisation  authorities  by  the  committee 

The  content  of  the  papers  will  cover  in  content  at  least 

design  and  development  standards  for  reliable  safe  and  secure  computer  systems 
verification  of  computer  system  performance 
hardware  and  software  reliability  standards 
definition  standards  for  computer  systems 


What  involvement  is  required  of  Members  of  the  TC  "Reliability.  Safety, 
and  Security"? 


It  IS  planned  that  the  committee  will  meet  four  (4)  times  per  year  twice  at  the  semi  annual  meetings  of  the 
International  Purdue  Workshop  at  Lafayette.  Indiana,  and  twice  at  agreed  upon  convenient  locations  in  the 
U S Some  members  take  part  in  the  International  Workshop  meetings  in  Europe 

The  involvement  of  the  TC7  members  includes 

— preparation  of  papers 

— review  of  papers 

— presentations 

— discussion  in  working  groups 

How  does  one  become  a member  of  the  TC  "System  Reliability,  Safety 
and  Security"? 

A candidate  qualifies  for  membership  by  twice  attending  TC7  meetings  Those  interested  in  the  programs  of 
the  committee  are  invited  to  attend  as  guests  They  should  contact  the  Chairman  of  the  TC 

Roy  W Yunker 
Director,  Process  Control 
PPG  Industries 
1 Gateway  Center 
Pittsburgh  PA  15222 

Phone  (412)434  3377 


CHAPTER  IX 


REPORT  OF  THE  PEAL  TIME 
OPERATING  SYSTEMS  COMMITTEE 


The  following  documents  are  included  here: 

1.  Minutes  of  TC  8 

2.  Up-to-Date  Report  TC  8 


-271- 


MINUTES  OF  TC  8 

The  main  activities  of  TC  8 are  still  concentrated  in 
Europe.  For  this  reason,  the  International  meeting  was  mainly 
used  to  present  and  discuss  the  Report  1-1-6  of  TC  8/E.  In 
the  many  informal  discussions,  partly  in  connection  with 
other  TC's,  there  was  a general  consensus  that  the  Report  of 
TC  8/E  was  a considerable  step  forward  towards  setting  up 
guidelines  for  a Real-Time  Operating  Systems.  Several  TC 
chairmen  and  representatives  of  both  manufacturers  and  users 
have  agreed  to  officially  comment  on  that  document.  This  will 
help  future  work  of  TC  8 to  produce  generally  approved  guide- 
lines . 
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1 . SCOPE  AND  GOALS  OF  TC  8 

The  scope  of  TC  8 on  Real-Time  Operating  Systems  is  to  consid- 
er DEFINITION,  CONSTRUCTION  and  USE  of  Real-Time  Operating  Systems 
(RTOS) . The  goal  of  TC  8 is  to  make  the  construction  of  RTOS ' s 
more  efficient  and  economical,  and  to  attain  maximum  reliability 
and  portability  through  the  development  of  auidelines  and  machine 
independent  concepts. 

These  guidelines  and  concepts  should  be  achieved  through  the 
interchange  of  IDEAS  and  INFORMATION,  through  the  use  of  a COMMON 
TERMINOLOGY  and  finally  through  the  definition  of  an  OPEN-ENDED 
MODEL  of  a RTOS  together  with  rules  for  expansion  and  reduction. 

The  promotion  of  this  model  should  be  achieved  by  involving 
RTOS-constructors  in  the  work  of  TC  8,  by  imparting  the  results  of 
TC  8 in  teaching  and  education  and  finally  by  proposing  these  re- 
sults to  the  INTERNATIONAL  PURDUE  WORKSHOP  and  consequently  to  the 
appropriate  national  and  international  organizations  responsible 
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2.  PROCESSES,  PROCESSORS  AND  THE  NEED  FOR  PROCESSOR  MULTIPLEXING 

Most  real-time  systems  can  be  considered  to  consist  of  a net- 
work of  intercommunicating  processes  running  on  a set  of  one  or 
more  processors. 

A PROCESS  is  defined  as  an  action  in  which  the  operations  are 
carried  out  one  at  a time. 

A PROCESSOR  is  capable  of  performing  the  operations  (data  man- 
ipulations) of  a process  (run  a process) . A processor  can  run  at 
most  one  process  at  a time. 

The  maximum  number  of  processes  that  can  be  physically  run  in 
parallel  is  equal  to  the  number  of  processors. 

Processors  which  are  exchangeable  with  regard  to  the  hardware 
configuration  and  the  processes  capable  of  being  run  by  them  can  be 
treated  as  a PROCESSOR  POOL  and  are  dispatched  with  common  dis- 
patcher primitives.  A processor  pool  with  its  set  of  exchangeable 
processors  is  identified  by  means  of  a PROCESSOR  POOL  DESCRIPTOR. 

It  is  assumed  that  for  each  process  which  can  run  independent- 
ly of  others  there  exists  a PSEUDO-PROCESSOR.  All  pseudo-  proces- 
sors have  to  be  provided  by  the  operating  system.  This  requires 
the  presence  of  some  operating  system  primitives  for  processor  mul- 
tiplexing. The  process  is  identified  within  the  operating  system 
by  means  of  a PROCESS  DESCRIPTOR. 
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It  is  convinient  to  represent  a network  of  processes  using  the 
following  diagrammatical  notation: 


to  represent  a process 


to  represent  process-process  communication 


to  represent  a processor  or  a pool  of 
identical  processors 


An  example  of  a network  described  in  this  manner  is  (fig  1). 


ABC 

fig.  1 


This  depicts  a network  of  four  processes  running  on  a three 


processor  configuration. 
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There  is  a need  to  tailor  the  RTOS  to  specific  applications. 
Tailoring  is  comprised  of  REDUCTION  and  EXTENSION  of  the  basic 
RTOS.  In  particular  this  tailoring  will  include  the  provision  of 
software  interfaces  to  process  peripherals.  The  fulfilment  of  this 
need  for  tailoring  requires  that  the  RTOS  be  highly  structured  and 
well  engineered. 

An  approach  embodying  a hierarchical  structure  was  adopted  as 
a reasonable  basis  for  the  RTOS  design  and  its  logical  management. 
The  hierarchy  is  considered  to  consist  of  LEVELS  OF  CONSTRUCTION, 
where  the  realization  of  a new  level  from  a lower  level  is  achieved 
by  a LAYER  (fig.  2).  The  effect  of  each  layer  can  be  defined  with 
respect  to  functions  available  at  lower  and  upper  boundaries. 
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This  can  be  represented  as  follows: 


level  3 ! A ! D ! F i G J 


level  2 ! A ! D 1 E ! 


level  1 ! A 1 B 1 C l 

fig.  2 

The  row  of  connected  rectangles  lists  the  functions  available 
at  that  interface  level.  A lower  boundary  function  may  be 
transmitted  without  any  change  to  the  upper  boundary  (e.g.  A)  or 
made  completely  invisible  (e.g.  B) . Some  new  functions,  not  ava- 
ilable at  the  lower  level  boundary,  can  be  introduced  by  the  layer 
(e.g.  F) . These  new  functions  will  be  implemented  within  the 
layer  making  use  of  the  functions  available  at  the  lower  boundary. 
This  is  optionally  indicated  by  lines  connecting  functions  at  adja- 
cent levels. 

The  model  for  a RTOS  to  be  defined  is  a logical  model,  i.e. 
it  is  to  be  implemented  by  an  appropriate  combination  of  hardware 
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and  software. 

The  KERNEL  is  considered  as  the  layer (s)  which  provides  any 
number  of  pseudo-processors  by  muliplexing  (physical)  processors. 
The  kernel  is  considered  essentially  strategy  independent. 

There  exist  on  each  level  of  implementation  naturally  embedded 
strategies.  The  choice  of  appropriate  data  structures  for  repre- 
sentation of  processes  as  well  as  the  sorting  algorithms  used  in 
the  ordering  or  selecting  of  list  elements  are  representative  of 
these  strategies. 

The  higher  levels  of  construction  are  necessary  to  provide 
both  a convenient  and  comprehensive  interface  for  'user  processes' 
and  higher  level  operating  system  functions. 


4.  BASIC  SYNCHRONIZATION 

It  is  important  to  recognize  that  any  synchronization  mechan- 
ism is  repeatedly  built  upon  a more  primitive  mechanism,  with  the 
most  primitive  being  hardware  synchronisation.  Thus  the  hardware 
has  to  provide  facilities  to  implement  primitives  which  exclude 
simultaneous  access  to  common  data. 

The  existence  of  two  synchronisation  primitives,  LOCK  and  UN- 
LOCK, is  assumed.  Both  are  considered  indivisible  operations  and 
are  not  simultaneously  executable  by  different  processors  on  the 
same  variable.  They  allow  the  realization  of  the  BUSY-WAITING 
state  of  the  physical  processors. 

The  LOCK  and  UNLOCK  primitives  are  used  to  bracket  operations 


The  presence  of  the  parameter  'v'  (LOCK VARIABLE)  shows  that  differ- 
ent groups  of  mutually  exclusive  operations  exist;  only  those  usina 
the  same  lockvariable  mutually  exclude  each  other.  'v'  has  two 
possible  states;  'LOCKED'  and  'UNLOCKED'.  The  locked  state  repre- 
sents the  fact  that  a process  is  executing  mutually  exclusive  oper- 
ations and  that  no  other  process  is  allowed  to  "pass"  throuqh  the 
LOCK  primitive  (with  the  same  lockvariable) . The  UNLOCKED  state  is 
the  reverse. 

In  systems  with  only  one  physical  processor  the  LOCK  and  UN- 
LOCK primitives  can  be  realized  with  interrupt  inhibition.  Whether 
it  is  posssible  to  differentiate  between  different  lockvariables 
depends  on  the  existing  hardware  (selective  interrupt  inhibition) . 
Structure  of  LOCK  and  UNLOCK  for  single  (physical)  processor  sys- 
tems : 


LOCK  (v) 

inhibit  interrupts  (selectively  corresponding  to  'v'). 
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UNLOCK  (v) 

enable  interrupts  (selectively  corresponding  to  'v'). 

In  systems  with  more  than  one  physical  processor  a busy-wait 
loop  for  processors  waiting  for  the  lockvariable  to  be  unlocked  has 
to  be  provided.  In  addition,  interrupts  still  have  to  be  inhibited 
for  two  reasons: 

- The  time  between  the  execution  of  the  LOCK  and  the  UNLOCK 
primitives  has  to  be  minimized,  because  during  this  time  other 
processors  may  stay  in  busy-wait  loops.  Interrupts  being  ser- 
viced between  LOCK  and  UNLOCK  extend  this  time  and  should 
therefore  be  inhibited,  if  possible. 

- A deadlock  situation  arises  when  a processor  stays  in  a loop 
waiting  for  a lockvariable  which  has  already  been  locked  by 
the  same  processor.  Such  a situation  is  possible  when  the 
processor  has  serviced  an  interrupt  between  the  execution  of 
the  LOCK  and  UNLOCK  primitives.  The  corresponding  interrupts 
must  therefore  be  inhibited  between  LOCK  and  UNLOCK. 

In  multiprocessor  systems  the  two  primitives  have  the  follow- 
ing qeneral  structure: 

LOCK  (v) 

switches  the  processor  executing  this  function  into  a 
non-interruptable  mode  and  then  checks  whether  the  lockvariable  'v' 
is  already  in  the  locked  state.  If  not,  'v'  is  locked  and  execu- 
tion of  the  mutually  exclusive  operations  is  started.  If  so,  the 
processor  is  switched  back  into  the  mode  it  was  previously  in  and 
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the  function  is  restarted  at  its  beginning,  thus  leading  to  a 
busy-wait  loop  until  the  lockvariable  is  switched  to  the  unlocked 
state  by  another  process.  This  other  process  is  presently  execut- 
ing mutually  exclusive  operations  locked  by  the  same  lockvariable. 

It  is  important  that  checking  'v'  and  putting  it  to  the  locked 
state  is  executed  as  an  indivisible  operation  which  itself  must  be 
mutually  exclusive  with  other  possible  accesses  to  'v' . This  fa- 
cility must  be  basically  supported  by  the  processor-hardware. 

UNLOCK  (v) 

switches  'v'  to  the  unlocked  state  and  switches  the  processor 
back  to  the  mode  it  was  in  before  it  executed  the  corresponding 
LOCK  primitive. 


5.  BASIC  SUPPORT  FUNCTIONS 


5.1  LI ST-MANAGEMENT 

A list  is  a possibly  empty  collection  of  elements,  which  share 
some  common  property.  Operations  on  lists  may  take  account  of  some 
ordering  strategy. 


Note:  Lists  may  be  implemented  using 

- linked  lists  in  the  conventional  sense, 

- fixed  length  arrays  of  elements, 

- subsets  of  more  general  lists,  with  bits  set  to  indi- 
cate membership  of  a particular  list. 


Within  all  levels  of  the  RTOS  kernel  list  management  functions 
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are  necessary.  They  are  defined  as  follows: 

INSERT  (el, list) 

inserts  the  element  'el'  into  the  list  'list'  according  to 
some  strategy. 

REMOVE  (el, list) 

selects  an  element  from  the  list  'list'  according  to  some 
strategy  and  returns  it  in  the  parameter  'el'.  The  element  is  re- 
moved from  the  list. 

LISTSIZE  (list, lenght) 

the  actual  number  of  listelements  within  the  list  'list'  is 
returned  in  the  parameter  'length'. 

NEXT  (el, list) 

based  on  the  possibly  implementation-dependant  linear  ordering 
of  the  list  'list'  (e.g.  increasing  addresses,  index  of  arrays, 
link  chain,  sequence  according  to  some  strategy)  the  function  NEXT 
returns  in  the  transient  parameter  'el'  the  successor  to  the  input 
element  'el'  of  the  list  'list'.  The  element  is  not  removed  from 
the  list.  The  first  element  of  the  list  is  obtained  if  input  to 
'el'  is  empty,  i.e.  the  parameter  'el'  contains  a predefined  empty 
element  symbol  (NIL) . If  the  list  is  empty  or  no  more  successor 
exists  the  output  to  'el'  is  the  empty  element  symbol. 

SEARCHFOR  (el , list, id_attribute) 

removes  one  element  of  the  list  'list',  which  has  the  identif- 
ication attribute  'id  attribute'  and  returns  it  to  the  parameter 
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'el'.  If  there  is  more  than  one  element  with  such  an  attribute  the 
selection  is  strategy-dependent.  The  attribute  consists  of  at 
least  a pair  of  parameters:  The  kind  of  attribute  (perhaps  denoted 
by  an  index  within  the  listelement)  and  its  special  value,  e.g. 
( 'process' ,task1 ) , (' priority ', 1 0) , ('key', 123).  Output  to  'el'  is 
empty  (NIL) , if  the  list  contains  no  element  with  the  specified  at- 
tribute. 

CHANGE  (list,  id_attribute,  change_attribute) 

the  list  'list'  is  searched  for  all  elements  with  the  identif- 
ication attribute  ' id_attribute ' . Within  these  elements  the  value 
of  the  attribute  specified  by  ' change_attribute ' is  reassigned. 
'change_attribute ' is  of  the  same  type  as  ' id_attribute ' and  con- 
tains both  kind  of  attribute,  which  has  to  be  changed,  and  the  new 
value  of  that  attribute. 


5.2  Context  Switching 

The  CONTEXT  of  a process  is  that  part  of  the  information  be- 
longing to  a process,  which,  when  the  process  is  actually  executed 
by  a processor  (process  is  in  the  RUNNING  state,  cf . par.  6) , is 
located  in  processor-specific  storage  (locations  and/or  registers) . 
This  storage  is  used  by  all  processes  running  on  that  processor. 
Although  size  and  structure  of  a context  may  vary  in  a wide  range, 
a context  exists  in  every  case. 

That  part  of  the  context  which  is  used  by  the  kernel  must  be 


> 


-286- 

TC  8 REPORT  Page  12 

saved  on  entering  the  kernel  and  is  restored  on  leaving  the  kernel; 
some  of  these  operations  are  performed  by  hardware  (e.g.  saving 
and  restoring  of  program  counter,  processor  status) . 

If,  within  the  kernel,  processes  have  to  be  switched,  two 
functions  operating  on  contexts  are  necessary: 

SAVE_CONTEXT  (process) 

moves  the  context  of  'process'  into  the  process  descriptor  of 
'process ' . 

RESTORE_CONTEXT  (process) 

restores  the  context  of  'process'  out  of  the  process  descrip- 
tor in  a way  that  will  enable  the  process  to  be  continued  on  exit 
from  the  kernel.  The  initial  state  of  the  context  of  a process 
stored  in  its  descriptor  is  defined  such  that  the  function  RESTORE 
CONTEXT  will  enable  the  process  to  start  correctly. 
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PROCESS  STATES: 

RUNNING The  process  has  a suitable  processor  allocated  to 

it. 

READY The  process  is  competing  for  a specific  processor 

or  one  of  a pool  of  processors. 

BLOCKED The  process  is  not  competing  for  a processor. 

The  process  is  waiting  for  a specific  condition  to  become  true  as  a 
consequence  of  the  operations  of  other  processes. 


PROCESSOR  STATES: 

ALLOCATED. .. .The  processor  has  a suitable  process  allocated  to 

it. 

NOTIFIED The  processor  has  a process  allocated  to  it  which 

may  have  to  be  exchanged  for  another  process. 

DEALLOCATED . .The  processor  has  no  process  allocated  to  it. 


DISPATCHER  LISTS 

We  assume  the  presence  of  different  lists  which  are  accessed 
and/or  modified  by  the  dispatcher  primitives. 
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- Each  process  descriptor  contains  the  following  elements: 

- identification  of  the  processor-pool  which  is  considered  to 
execute  the  corresponding  process  (this  information  may  be 
implicite) . 

- storage  to  save  its  context 

- Each  processor  pool  descriptor  contains  the  following 

elements : 

- the  identification  of  the  RUNNING  process  (if  any)  for  each 
processor  of  the  pool 

- a list  of  all  processes  which  are  READY  to  run  on  that  pool 
(READYLIST) . 


Note:  Asynchronous  program  executions  must  exclude  each 
other  in  time  while  accessing  shared  data.  Regarding  the 
data  accessed  by  the  dispatcher  primitives,  mutual  exclu- 
sion is  achieved  using  the  LOCK  and  UNLOCK  primitives. 


DISPATCHER  PRIMITIVES 

ASSIGN 

Removes  a process  (if  there  is  any)  from  the  readylist  of  the 
pool  of  the  processor  executing  the  primitive,  assigns  it  to  this 
processor,  switches  the  removed  process  from  READY  to  RUNNING  and 
the  executing  processor  from  DEALLOCATED  to  ALLOCATED.  It  restores 
the  context  of  the  removed  process  calling  RESTORE_CONTEXT . 

If  there  is  no  READY  process  in  the  corresponding  readylist, 
the  processor  remains  in  the  DEALLOCATED  state  and  waits. 
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Note:  If  'idle'  processes  exist,  there  is  always  a READY 
process  in  the  readylist  and  the  processor  will  not  rema- 
in in  the  DEALLOCATED  state.  If  no  'idle'  process  ex- 
ists, the  REDISPATCH  function  (cf.  par.  7)  will  cause 
the  processor  to  leave  the  DEALLOCATED  state.  It  is  im- 
plementation dependent  whether  a processor  waiting  in  the 
DEALLOCATED  state  should  periodically  check  for  the  pres- 
ence of  READY  processes.  If  not,  the  NOTIFY  and  REDIS- 
PATCH functions  are  mandatory,  if  yes,  they  may  be  omit- 
ted in  non-preemptive  systems  (cf.  par.  7). 


RESIGN 

Decouples  the  process  from  the  processor  executing  the  primi- 
tive and  saves  its  context  calling  SAVE_CONTEXT . Inserts  the  pro- 
cess in  the  readylist  of  the  corresponding  processor-  pool, 
switches  the  process  from  RUNNING  to  READY  and  the  executing  pro- 
cessor from  NOTIFIED  to  DEALLOCATED.  An  embedded  strategy  for  the 
ordering  of  the  READY  processes  in  the  readylist  is  used  by  the 
called  INSERT  function. 

BLOCK 

Decouples  the  process  executing  the  primitive  from  its  allo- 
cated processor  and  saves  its  context  calling  SAVE_CONTEXT . 
Switches  the  process  from  RUNNING  to  BLOCKED  and  the  processor  from 
ALLOCATED  to  DEALLOCATED. 

READY  (process) 

Switches  'process'  from  BLOCKED  to  READY  and  inserts  it  into 
the  readylist  of  the  corresponding  processor-pool.  An  embedded 
strategy  for  the  ordering  of  the  READY  processes  in  the  readylist 
is  used  by  the  called  INSERT  function. 


T*^ 
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NOTIFY  (processor-pool) 

Switches  a processor  of  the  'processor-pool'  from  ALLOCATED  to 
NOTIFIED  by  sending  a stimulus.  If  the  processor  receiving  the 
stimulus  is  in  the  DEALLOCATED  or  NOTIFIED  state,  no  change  of 
state  occurs.  If  the  pool  consists  of  more  than  one  processor,  se- 
lection of  the  processor  receiving  the  stimulus  is  subject  to  some 
embedded  strategy.  (It  is  assumed  that  processors  in  the  DEALLO- 
CATED state,  if  there  are  any,  are  selected  first.) 

As  a result  of  receiving  the  stimulus  the  processor  will  exe- 
cute the  REDISPATCH  function  (see  par.  7) . 


Note:  The  reason  for  using  a stimulus  rather  than  a call 
to  start  the  REDISPATCH  function  is  that  the  sending  and 
the  receiving  processor  in  general  are  not  identical  and 
executing  completely  asynchronously  at  the  time  of  the 
notification.  If  the  sending  and  receiving  processors 
are  identical,  the  NOTIFY  primitive  can  lead  to  a direct 
call  of  the  REDISPATCH  function. 


RESUME 

Switches  the  processor  executing  the  primitive  from  NOTIFIED 
to  ALLOCATED.  Thus,  the  processor  will  continue  to  execute  its 
RUNNING  process  after  leaving  the  kernel. 
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7.  PREEMPTION  AND  PROCESSOR  REDISPATCHING 

Separation  of  a RUNNING  process  from  its  processor  (executing 
the  RESIGN  primitive)  in  order  to  free  this  processor  to  ASSIGN 
another,  presently  more  important  process,  is  called  preemption. 

As  opposed  to  the  RESIGN  primitive  the  BLOCK  primitive  is  exe- 
cuted by  a process  which  voluntarily  stops  execution  and  thus  frees 
a processor. 

Preemption  is  not  necessarily  a property  of  a RTOS.  If  there 
are  either  always  enough  processors  to  execute  the  necessary 

processes,  or  if  the  different  competing  processes  are  known  to  al- 
ways execute  the  BLOCK  primitive  in  time  to  allow  the  other 
processes  to  run  correctly,  a simpler  model  of  process-  and  proces- 
sor states  and  state  transitions  is  possible  (see  fig.  4) . 

process  states  processor  states 


fig . 
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Note:  A system  with  'idle'  processes  will  in  most  cases 

need  preemption. 

In  systems  with  preemption  a preemption  may  become  necessary 
whenever  a READY  process  has  been  added  to  a readylist  or,  more 
general,  when  changes  have  been  made  to  the  readylist.  If  after  a 
change  to  the  readylist  a (possible)  preemption  is  desired,  the 
process  which  made  the  change  has  to  NOTIFY  the  corresponding  pro- 
cessor- pool.  A processor  of  this  pool  will  then  execute  the  RE- 
DISPATCH function: 

REDISPATCH 

The  processor  executing  this  function  is  either  in  the  NOTI- 
FIED or  ir  the  DEALLOCATED  state.  In  the  DEALLOCATED  state,  it 
will  execute  the  ASSIGN  primitive  and  thus  start  execution  of  a 
previously  READIED  process,  if  there  was  any,  or  stay  in  the  DEAL- 
LOCATED state.  In  the  NOTIFIED  state,  it  will  check  whether  it  is 
more  important  to  RESUME  its  RUNNING  process  or  to  RESIGN  this  pro- 
cess and  to  ASSIGN  a new  one. 
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Note  1:  The  detailed  construction  of  the  REDISPATCH  func- 
tion is  implementation-dependent.  The  RESUME  function 
can  be  avoided,  if  the  NOTIFY  primitive  is  only  executed 
when  the  conditions  which  lead  to  preemption  are  true. 
It  also  can  be  avoided,  if  the  REDISPATCH  function  uncon- 
ditionally RESIGNS  the  RUNNING  process,  even  if  this  same 
process  is  then  ASSIGNed  again. 

Note  2:  The  voluntary  releasing  of  a processor  by  a pro- 
cess in  favour  of  other  processes  is  considered  a preemp- 
tion. Accordingly,  such  processes  will  execute  the  NOTI- 
FY primitive  which  triggers  the  REDISPATCH  function. 
Since  in  this  case  the  sending  and  receiving  processors 
of  the  NOTIFY-stimulus  are  always  identical,  simple  im- 
plementations are  possible  (see  oar.  6,  description  of 
the  NOTIFY  primitive) . 


8 . PROCESS  MANAGEMENT 

It  is  necessary  to  have  functions  for  the  CREATION  and  DELE- 
TION of  processes  and  for  the  STARTING  and  TERMINATING/  Ki.T L'Nc.  of 
processes.  Those  Functions  also  introduce  two  new  process  states: 
UNDEFINED  and  INACTIVE.  The  new  functions  and  states  are  expressed 
in  the  following  state  transition  diagram  together  with  existing 
functions  and  states  (fig.  5): 
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Note  that  only  the  terminal  nodes  of  the  tree  are  actual  process 
states.  All  other  states  are  for  convenience  of  description  only. 

The  new  process  states  are: 

UNDEFINED ... .An  undefined  process  is  non-existent. 

INACTIVE The  process  and  its  process  descriptor  have  been 

created  but  the  process  is  inactive  and  not  subject  to  control  by 
the  dispatcher. 

The  process  management  functions  are: 

CREATE 

Takes  a,  set  of  system  elements  (assumed  to  be  'building 
blocks',  created  by  previous  stages  of  software  construction,  e.g. 
compiler,  linker,  etc.)  and  builds  a process  and  its  process  des- 
criptor. The  process  thus  constructed  is  put  into  the  INACTIVE 
state . 

START  (process) 

Switches  the  process  from  the  INACTIVE  to  the  READY  state  with 
appropriate  initialization  (e.g.  process  descriptor,  process  par- 
ameters, etc.).  The  process  thus  becomes  ACTIVE  and  RUNNABLE. 

RETIRE 

The  RUNNING  process  voluntarily  retires  from  further  dispatch- 
er influence  and  is  placed  in  the  INACTIVE  state. 


TERMINATE  (process) 
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The  process  'process'  is  switched  from  whichever  ACTIVE  state 
(RUNNING,  READY,  BLOCKED)  that  it  is  currently  in  into  the  INACTIVE 
state. 

DELETE  (process) 

Removes  the  process  'process'  from  the  system  and  releases  any 
resources  held  by  it  (e.g.  process  descriptor,  main  storage, 
etc. ) . 


9.  SYNCHRONIZATION  FUNCTIONS 

Synchronization  tools  are  necessary  to  coordinate  processes. 
The  kernel  is  now  suited  to  implement  a more  powerful  set  of  syn- 
chronization functions  in  which  the  physical  processors  are  discon- 
nected from  processes  going  to  'wait'. 

Considerations  of  the  fundamental  requirements  posed  by  a syn- 
chronizing concept  result  in  the  following  definition  of  a syn- 
chronization model  (fig.  7)  and  two  actions  performed  on  it. 
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insert  information  into 
information  list 
remove  at  least  one  process 
from  process  list,  deliver 
information  to  it  and  READY  it 


T- 


WAIT-ACTION  (information) 

information  list  = (empty)  insert  executing  process 

into  process  list,  BLOCK 
executing  process 

= (not  empty)  remove  at  least  one  element 
from  information  list, 
deliver  it  to  executing  process 

From  the  definition  of  these  two  actions  it  is  obvious  that 
only  one  of  the  two  lists  is  present  at  a time  and  that  both  lists 
have  identical  elements  (process  identification  and  information  as 
minimal  set) . Therefore  we  only  need  space  for  one  list  and  only 
one  set  of  list  functions  to  implement  the  synchronization  model. 

To  distinguish  the  two  lists  a counter  is  introduced  into  the  des- 
criptor with  the  following  meening: 

counter  = 0 : information  list  = (empty)  AND 

process  list  = (empty) 

A 
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counter  > 0 : information  list  = (not  empty)  AND 

process  list  = (empty) 

counter  < 0 : process  list  = (not  empty)  AND 

information  list  = (empty) 

abs (counter)  = number  of  elements  in  either  list. 

These  relations  assume  that  the  corresponding  lists  exist.  It 
should  be  mentioned  that  all  strategy-dependent  parts  of  the  syn- 
chronization functions  are  embedded  into  the  list  functions. 

The  counter  and  the  corresponding  list  form  an  entity  called  a 
SYNCHRONIZATION  ELEMENT. 

To  avoid  any  confusion  with  established  synchronization  con- 
cepts, the  two  functions  are  now  called  INC  (send-  action)  and  DEC 
(wait-  action) , reflecting  their  operation  on  the  counter. 

At  least  two  data  elements  are  accessed  by  the  two  functions: 
The  synchronization  element  itself  and  the  readylist  of  a 
processor-pool.  Simultaneous  access  to  these  elements  has  to  be 
excluded  using  the  LOCK/  UNLOCK  functions.  The  two  functions  are 
described  as  follows: 

INC  (synchelement , info) 

The  counter  of  the  synchronization  element  'synchelement'  is 
incremented.  If  the  counter  is  now  less  than  or  equal  to  zero,  at 
least  one  process  is  waiting  in  the  process  list.  One  process  is 
removed,  switched  to  the  READY  state  and  the  information  'info'  is 
passed  to  the  place  formerly  defined  when  the  now  removed  process 
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executed  the  corresponding  DEC  function.  The  processor-  pool  of 
the  removed  process  is  (conditionally)  NOTIFIED  (cf . par.  7) . If 
the  counter  is  greater  than  zero,  no  process  is  waiting  and  the  (i- 
dentif ication  of  the)  sending  process  and  the  information  'info* 
are  inserted  in  the  information  list. 

DEC  (synchelement , info) 

The  counter  of  the  synchronization  element  'synchelement'  is 
decremented.  If  the  counter  is  now  less  than  zero,  no  information 
is  available.  The  process  executing  the  function  and  a pointer  to 
'info'  (the  place  where  the  information  will  have  to  be  put)  is  in- 
serted into  the  process  list  and  this  process  is  put  in  the  BLOCKED 
state.  The  executing  processor  becomes  free  and  executes  the  AS- 
SIGN function. 

If  the  counter  is  equal  to  or  greater  than  zero,  the  necessary 
information  is  removed  from  the  information  list  and  passed  to  the 
return  parameter  'info*. 
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10.  REALIZATION  OF  SOME  HIGHER  LEVEL  SYNCHRONIZATION  CONCEPTS 


Higher  level  synchronization  functions  can  be  realized  using 
INC  and  DEC.  Usually,  the  interface  to  the  higher  level  synchroni- 
zation tools  constructed  in  this  layer  is  built  by  SVC  (supervisor 
call)  or  TRAP  instructions. 

The  following  examples  of  some  known  synchronizing  concepts 
illustrate  the  method. 


10.1  SEMAPHORE 

The  semaphore  concept  introduced  by  E.W.  Dijkstra  can  be  re- 
alized easily. 

For  each  semaphore  one  synchelement  sys_sema  must  be  initial- 
ized. (Initial  value  of  sys_sema. counter  >=  0 ) 

Implementation  of  the  two  operations  on  semaphores: 

V(sema)  = INC  (sys_sema,NIL) ; 

P(sema)  = DEC  (sys_sema,NIL) ; 

The  use  of  NIL  implies  that  the  information-queue  does  not 
exist  and  all  operations  which  are  performed  on  it  within  INC  and 
DEC  may  be  omitted  (to  speed  up  operation) . 

10.2  MESSAGE 

For  each  process  one  synchelement  sym  proc  must  exist  (crea- 


tion static  or  dynamic) . 


Buffer  allocation  under  process  control  or  RTOS  control  for 
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internal  use  of  messages. 

SENDM (proc , message)  = 
WAITM (message)  = 


INC (sym_proc, message)  ; 
DEC(sym  actproc, message)  ; 


10.3  MONITOR 

Monitors  are  realized  based  on  the  definition  of  C.A.R. 
Hoare . 

A monitor  is  a collection  of  associated  data  and  procedures 
working  on  this  data.  Processes  may  at  any  time  attempt  to  call 
such  a monitor  procedure;  however  only  one  process  at  a time 
succeeds  in  entering  it.  Signal  and  wait  operations  on  condition 
variables  are  provided  within  the  monitor  to  delay  a process.  When 
a process  signals  a condition  it  must  wait  until  the  resumed  pro- 
cess (if  there  is  one)  permits  it  to  proceed. 

For  each  monitor  the  following  synchelements  are  necessary: 

symonjmonid  - to  realize  exclusive  entry  into  the  monitor 

syurgent_monid  - to  notify  which  signalling  processes  are 

waiting 

sycond_cvar  - one  for  each  condition  variable 

monid  = identifier  for  monitor 


cvar 


identifier  for  condition  variable 


i. 


■ 

I 
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Translation  of  monitor  syntax  into  supervisor  calls  of  syn- 
chronization functions  can  be  expressed  as  follows: 

ENTER  (monid) ; 
monid.procedurename  ->  procedurename; 

EXIT  (monid) ; 

cvar. signal  ->  SIGNAL  (cvar, monid) ; 

cvar.wait  ->  WAIT  (cvar, monid) ; 

Implementation  of  these  synchronization  functions  by  the  ele- 
mentary synchronization  functions  INC  and  DEC: 


ENTER  (monid) 
EXIT  (monid) 


WAIT  (cvar, monid) 


SIGNAL  (cvar, monid) 


= DEC  (symon_monid,NIL) ; 

= IF  syurgent_monid. counter  < 0 
THEN  INC  (syurgent_monid,NIL) 
ELSE  INC  (symon_monid,NIL) ; 

= EXIT  (monid) ; 

DEC  (sycond_cvar ,NIL) ; 

= IF  sycond_cvar .conter  < 0 THEN 
BEGIN  INC  (sycond_cvar , NIL) ? 

DEC  (syurgent  monid, NIL) ; 


END; 

If  every  SIGNAL  occurs  as  the  last  statement  of  its  monitor 
procedure,  the  synchelement  syurgent_monid  can  be  omitted  together 
with  all  operations  on  it. 
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ENTER  (monid) 

EXIT  (monid) 

WAIT  (cvar, monid) 

SIEXIT  (cvar, monid) 


DEC  (symon_monid,NIL) ; 

INC  (symon_monid ,NIL) ; 

INC  (symon_monid,NIL) ; 

DEC  (sycond_cvar,NIL) ; 

IF  sycond_cvar .conter  < 0 
THEN  INC  (sycond_cvar ,NIL) 
ELSE  INC  (symon  monid, NIL) ; 


More  complex  monitors  may  be  implemented  if  WAIT  and  SIGNAL 
are  replaced  by  message  functions. 


1 1 . INPUT  / OUTPUT 

Input/Output  is  defined  to  be  the  movement  of  data  into  or  out 
of  the  system  and  can  be  viewed  as  an  extension  of  inter-process 
communication. 

Input/Output  processing  is  considered  to  consist  of  two  coo- 
perating parallel  processes,  one  process  running  in  a general  pur- 
pose processor  and  the  other  process  running  in  a conceptually  sep- 
arate I/O  processor.  Depending  upon  the  hardware  configuration, 
the  I/O  process  may  be  executed  on  a seperate  physical  processor  or 
alternatively,  the  logic  of  the  I/O  process  may  actually  be  execut- 
ed by  a general  purpose  processor. 

The  configuration  of  two  physically  separate  processors  is  re- 
presented in  fig.  8 


X - ... 


' 

where  denotes  hardware  source/sink 

In  this  figure  process  2 is  the  I/O  process  running  on  the 
physically  separate  I/O  processor  B. 

The  configuration  of  two  conceptually  separate  processors,  re- 
alized by  only  one  physical  processor,  is  represented  in  fig.  9. 


i 


f ig . 9 


denotes  the  hardware  logic  which  is  conceptually  a process 
communicating  betweerj  hardware  source/sink  and  the  I/O  port  of  the 
processor  A. 


In  this  figure  the  conceptual  I/O  processor  is  represented  by 
the  dash-dot  line.  Two  cooperating  processes  run  on  this  conceptu- 
al processor:  Process  2 - a software  I/O  process  actually  running 
on  the  physical  processor  A and  process  H - a hardware  process. 


Note  that  process  2 is  not  scheduled  by  the  dispatcher  but  is 
scheduled  by  the  hardware  interrupt  which  thus  provides  an  alterna- 
tive and  more  primitive  method  of  processor  multiplexing. 


A more  conventional  view  of  this  configuration  is  shown  in 


fig.  10 
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fig.  10 

The  hardware  source/sink  now  includes  the  hardware  process  H and 
the  I/O  communication  port  of  the  processor  A. 
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12.  EXCEPTION  HANDLING 

Four  types  of  exception  handling  have  been  identified: 

(a)  exceptions  detected  in  function  calls 

(b)  exceptions  (excluding (a) ) attributable  to  the  running 
process  (e.g.  arithmetic  overflow,  store  violation) 

(c)  exceptions  not  attributable  to  the  running  process  and 
detected  by  the  operating  system  (e.g.  store  parity  fai- 
lure) 

(d)  exceptions  detected  by  one  process  and  attributable  to 
another  process 

Type  (a)  exceptions  are  best  handled  by  a return  parameter  of 
each  function. 

Type  (b)  exceptions  can  optionally  be  handled  by  a user  de- 
fined routine. 

Type  (c)  exceptions  must  be  handled  by  the  operating  system. 

Note  that  exceptions  of  type  (b)  and  (c)  occur  synchronously 
a3  a direct  result  of  executing  a processor  instruction. 

Type  (d)  exceptions  are  the  responsibility  of  the  application 
system  and  are  not  to  be  handled  by  the  operating  system. 

It  is  not  appropriate  to  state  the  action  to  be  taken  upon  the 
occurrence  of  an  exception  as  part  of  a set  of  guidelines  or  stan- 
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dards.  However,  the  guidelines  should  include  some  mechanism  by 
which  the  exceptions  may  interface  with  the  process  above  the  ker- 
nel. 


i 


1 


One  internal  function  is  introduced  to  support  the  handling  of 
type  (b)  and  (c)  exceptions: 

EXCEPT I ON_RECEIPT 

The  function  receives  the  exception  upon  its  ocurrence.  It 
must  determine  whether  the  exception  is  of  type  (b)  or  (c) . If  it 
is  of  type  (b)  and  a user  defined  routine  has  been  specified,  con- 
trol is  transferred  to  that  routine  after  appropriate  manipulation 
of  process  descriptor,  stack (s)  etc.  For  type  (b)  and  (c) , when  no 
user  defined  routine  has  been  specified,  control  is  transferred  to 
an  operating  system  exception  handling  process. 

To  enable  the  process  to  control  the  setting  of  the  exception 
handling  routine  two  functions  are  introduced: 

EXCEPTION_ON  (address  of  user  defined  routine) 

sets  the  exception  handling  routine  for  type  (b)  exceptions  to 
a user  defined  routine  identified  in  the  parameter. 

EXCEPT I ON_OFF 

sets  the  exception  handling  routine  for  type  (b)  exceptions  to 
the  default  option  provided  by  the  operating  system. 


One  important  decision  has  to  be  taken  by  a user  defined  ex- 
ception handling  routine,  that  is  to  decide  whether  the  process  can 
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continue  or  whether  it  must  be  stopped.  In  the  latter  case  the 
process  management  function  RETIRE  will  be  called.  For  the  former 
case  the  following  function  is  introduced: 

EXCEPT ION_RETURN 

Returns  control  back  to  the  operating  system  to  enable  it  to 
do  any  necessary  manipulations  of  process  descriptor,  stacks,  etc. 
before  returning  control  to  the  exception  producing  process. 


TC  8 REPORT 


-311- 


Page  37 


13.  DEFINITION  OF  AN  OPERATING  SYSTEM  KERNEL 

According  to  the  model  presented  in  fig.  2 the  proposed  oper- 
ating system  functions  and  their  hierarchical  relations  are  shown 
in  fig.  11 

The  first  three  levels  of  the  system  can  be  regarded  as  a KER- 
NEL system.  Two  types  of  entries  to  that  kernel  can  be  distingu- 
ished : 

synchronous  or  procedure-like  entries  (called  by  a process) : 

INC,  DEC,  NOTIFY 
EXCEPTION_ON,  EXCEPTION_OFF 

asynchronous  or  interrupt-like  entries: 

REDISPATCH 
EXCEPTION  RECEIPT 


NOTES : 

- "EXCEPTION  HANDLING”  on  level  2 represents 
some  necessary,  but  not  yet  defined  functions 
to  handle  exceptions; 

- the  process  management  functions  will  also 
need  additional  functions  within  the  kernel 
and  are  not  included  in  the  figure; 

- other  functions  to  access  kernel  data,  to  re- 
order lists,  etc.,  will  have  to  be  included 
in  the  kernel; 

- the  various  relations  of  the  LOCK  and  UNLOCK 
functions  are  not  explicitly  shown  in  the 
figure. 
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fig.  11b 


for  the  design  of  the  operating  system.  The  objectives  of  TC  8 for 
the  next  year  are  to  complete  the  kernel  and  to  continue  work  on 
higher  levels  of  construction. 

Outstanding  work  on  the  kernel  includes  the  following: 

- the  process  management  and  exception  handling  functions  have 
to  be  fully  specified. 

- kernel  data  management  - this  covers  all  the  imbedded  strateg- 
ies including  the  ordering  and  reordering  of  lists  etc.  It 
also  includes  strategies  for  selective  lock-outs  on  data  areas 
which  avoid  deadly  embrace  situations. 

- system  configuration  and  reconfiguration  - both  in  response  to 
manual  requests  and  as  a consequence  of  exception  recovery. 

i 

Among  the  topics  to  be  tackled  in  the  layers  above  the  kernel 

are : 

| 

- resource  allocation 

j 

- store  management 

| 

It  is  likely  that  this  program  of  work  will  have  repercussions 


on  existinq  specifications  and  therefore  a further  iteration  of 
these  can  be  expected. 
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NOTATION  OF  THE  OPERATING  SYSTEM  FUNCTIONS 

This  appendix  shows  in  a more  detailed  notation  the  construc- 
tion of  the  described  operating  system  functions.  As  opposed  to 
the  general  descriptions  in  the  report,  the  detailed  notations  may 
contain  implementation  dependent  parts. 

A PASCAL-like  notation  and/or  flowcharts  are  used  to  describe 
the  functions.  The  numbering  of  the  paragraphs  corresponds  to  the 
first  part  of  the  report. 

Comments  on  the  PASCAL-like  notation: 

Not  all  data  elements  used  are  described  completely;  the  data  des- 
criptors are  such  that  the  functions  described  are  understood  with- 
out unnecessarily  prescribing  a specific  implementation. 
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Comments  on  the  flowcharts: 

The  following  graphical  elements  are  used: 
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synchronous  entry 


synchronous  exit 


operation (s) 


conditional  branches 


asynchronous  entry 


asynchronous  exit 
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A. 4.  Basic  Synchronization 
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! 


! 

1 

1 

I 

1 


enable  interrupts 
( *selectively*) 


! 


( 


T 

1 


( UNLOCK  ) 

! 

j 

T v: =unlocked  T 

! 

i 

1 enable  interrupts  f 
t (*selectively*)  ) 


parameter:  v 
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Pascal  notation: 

TYPE  protection  = (locked , unlocked) ; 

PROCEDURE  LOCK  (VAR  v:  protection); 
BEGIN  inhibit 

WHILE  v = locked  DO 
BEGIN 

enable;  inhibit 
END; 

v : =locked 
END; 

PROCEDURE  UNLOCK  (VAR  v:  protection) ; 
BEGIN 

v:=unlocked 

enable 

END; 


where  enable  - procedure  to  enable  interrupts 
inhibit  - procedure  to  inhibit  interrupts 


11 


f 


! 

I 


1 
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A.6.  Process-  and  Processor  States 


( ASSIGN  ) 


I 

j < 

I no  1 

< READY  process  exists  >->-1  wait  1 

1 


T l6CK  riockvariable  o£  pool)  T 

1 (*pool  of  the  executing  processor*)  I 

I 


1 REMOVE  (newproc,  readylist) 

1 (*readylist  of  executing  processor*) 

1 
1 


X 

T state  of  newproc:*  RUNNING  T 
l state  of  processor:3  ALLOCATED  I 
jl actual  process  : =newproc 


1 RESTORE  CONTEXT  Tnewproc)  1 


l UNLOCK  (lockvariablo  of  pool!  T 
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r 


1 state  of  executing  processor : “DEALLOCATED  1 


! 

( ) 


■ 
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( RFAdY)  parameter:  process 

I 

1 

T LOCK  (lockvariablo  of  pool)  T 

l (*pool  of  processors  identified  in  the  des-  1 
I criptor  of  'process',  not  necessarily  ident-  ! 

1 ical  with  the  pool  of  the  executing  processor*)  1 

! 

T INSERT  (process  7readyl ist)  T 
I (*readylist  of  that  pool*)  1 

1 

T~  state  ot  process  ? "READY  1 

I 

I UNLOCK  (lockvariablo  of  pool)  T 
1 
! 

( ) 


( NOTIFY  ) 

J 


parameter:  pool 


1 


no  . -<  DEALLOCATED  processor  in  pool  available  yes 

1 I 

1 1 

1 select  a processor,  whose  T T select  a DEALLOCATED  1 

! 'actual  process'  ha3  J ! processor  ! 

1 lowest  priority  l 1 ! 

n — 1 

i 

i 

T send  stimulus  (^interrupt*)  to  this  processor  T 
J state  of  this  processor : -NOTIFIED 1 


I 


(' 


') 


PROCEDURE  REDISPATCH; 

BEGIN 

IF  processor. state=notif ied 

THEN  IF  preempt  (^conditions  to  redispatch  processor  are  true*) 
THEN  BEGIN  resign; 

assign 

END 

ELSE  resume 

ELSE  assign 
end 
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simplified  version  (c.f.  par.  7,  note  1): 


/ 


I 

1 

I 


t ASSIGN  1 
l 
1 

( ) 

/ 


PROCEDURE  REDISPATCH; 
BEGIN 


IF  processor .state=notif ied  THEN  resign; 
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A.  9.  SYNCHRONIZATION  PRIMITIVES 


Definition  of  data  types  used  by  the  synchronization 


functions : 


TYPE  synchelement  = RECORD 


counter  j integer; 


: list  (*  OF  listelement  *) 


END; 


TYPE  listelement  = RECORD 


proc  : processid; 

info  ; buffer 


END; 


TYPE  list 


definition  of  an  arbitrary  list  structure; 


TYPE  buffer 


definition  of  an  arbitrary  buffer  or  a 
pointer  to  an  arbitrary  buffer; 


TYPE  processid  * RECORD 

pool  : processorid; 

(*  other  information  *) 

END; 

TYPE  processorid  = reference  to  processor  pool  descriptor; 


VAR  actproc  : processid;  (*  identification  of  the  running  pro- 
cess exists  for  each  processor  *) 


i 
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Definition  of  elementary  synchronization  functions  INC  and  DEC: 

PROCEDURE  INC  (VAR  syname  : synchelement ; 

VAR  info  : buffer) ; 

VAR  listel  : listelement; 

BEGIN  syname. counter  :*  syname. counter  + 1 

IF  syname. counter  <*  0 (*  test  for  waiting  process  *) 

THEN  BEGIN 

remove  (listel, syname. pil) ; (*  remove  waiting  process  *) 
listel. infoA  :=«  info;  (*  pass  address  of  info  to  address 

specified  by  removed  process  *) 
ready  (listel .proc) ; (*  ready  the  waiting  process  *) 

notify  (listel. proc. pool) ; (*  notify  the  corresponding 

processor-pool  *) 

END 

ELSE  insert  ( (actproc, info) , syname. pil)  (*  no  process 

waiting,  insert  the  process 
executing  the  INC  plus  the 
address  of  the  send  info  *} 
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PROCEDURE  DEC  (VAR  syname  : synchelement , 

VAR  info  : buffer) ; 

VAR  listel  : listelement 

BEGIN  syname. counter  :=  syname. counter  - 1 (*  decrement  counter  *) 

IF  syname. counter  <0  (*  check  if  information  available  *) 

THEN  BEGIN 

insert  ( (actproc , Ainfo) , syname .pil) ; (*  no  info  avai- 
lable, insert  the  process  executing  DEC  plus  the 
address  of  the  info  to  be  sent  *) 
block;  (*  block  executing  process  *) 
assign;  (*  assign  new  process  to  processor  *) 

END 

ELSE  BEGIN 

remove  (listel, syname. pil) ; (*  info  is  available  in  the  list  *) 
info  ;=  listel. infoA;  (*  pass  address  of  info  to  result 

parameter  *) 
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REPORTS  OF  THE  AD-HOC  COMMITTEE  ON 
MICROPROCESSORS /MICROCOMPUTERS 
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The  following  documents  are  included  here. 


1.  Letter  of  Mr.  Koji  Yada  re..  Microcomputer  Working 
Group  of  IPW-J. 

2.  "Description  of  Japan  Microcomputer  Club,"  by  Mr. 
Koji  Yaaa. 

3.  "Technical  Trends  in  Computing  Instrumentation," 
by  Mr.  Koji  Yada. 

4.  "Microprocessors  in  Japan,"  by  Jyoichi  Mori,  Hiroaki 
Tajima,  Morihiko  Tajima,  and  Yoshifuni  Okada. 


Computer 


5.  Volumes  1 and  2 of  Micro 


News . 


ELECTROTECHNICAL  LABORATORY 
TANASH1  BRANCH 

5-4- J MUK OOAI-MACHI.  TANASHI-SHI, 

TOKYO,  JAPAN 
TELEPHONE:  0424  <61>  2141 


Prof.  Theodore  J.  Williams 

Purdue  Laboratory  for 

A pplied  Industrial  Control 

102  Michael  Golden 

Purdue  University 

West  Lafayette,  Indiana  47907 

U.S.A. 


November  25,  1977 


Microcomputer  Working  Group  IPW-J  was  established  on  November, 
1977.  We  had  the  first  meeting  of  this  group  on  November  18.  Then,  it  was 
decided  that  we  have  about  one  meeting  per  a month.  You  can  see  the  theme 
of  this  meeting  in  Appendix  1.  Next  meeting  is  to  be  held  in  January,  1978 
on  the  theme  shown  in  Appendix  2.  You  will  have  a report  of  this  meeting 
later. 

In  Japan,  there  are  several  Microcomputer  Committees.  I will 
introduce  some  of  them.  Microcomputer  Committee  of  JEIDA  makes 
surveys  of  microcomputers,  especially,  it  investigates  State-of-the-art 
of  foreign  microcomputers,  or  investigates  of  marketing. 

Microcomputer  Committee  of  NOMA  has  discussions  about  the  impact  of 
microcomputer  technology  on  the  society,  and  makes  several  reserchcs 
on  Delphi  method.  I am  a member  of  this  group. 

You  can  see  Japan  Microcomputer  Club  in  another  sheet.  I am  an  organizer 
of  this  club.  We  issue  a publication  "Microcomputer  News". 
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And  also  Computing  Instrumentation  Committee  makes  a survey  of  micro- 
computers. Especially  it  investigates  applications  of  microcomputers  for 
Smart  Instruments,  or  Laboratory  Automation.  Enclosed  pleuse  find  a 
copy  of  the  outline.  Also  enclosed  are  pamphlets  that  introduce  Japanese 
microcomputers  we  have  developed. 

Sincerely  yours, 

/<*/-.’  (\ 
Koji  Yada 
Computer  Center 

CC;  Dr.  Williams  (Purdue  University) 

Mr.  Yoel  Keiles  (Honeywell) 

All  Microcomputer  Committee  Members 
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Appendix  1 


Microcomputer  Working  Paper 


Koji  Yada 

Microcomputer  Working  Group 
IPW-J 


Group  1 

° Microcomputer  Development  Technology 
° Debugging  Tools 

Group  2 

° Limits  of  High  Level  Language  for  Microcomputer 
° Software  for  Microcomputer  Control  Systems 

Group  .'1 

° Benchmark 

• Evaluation  for  Performance 
•Standardization  for  Software  Tools 

Reliability  and  Environment  of  Microcomputer  for  Industrial  Control 
Systems 

° Concepts  of  Microcomputer 
Group  4 

0 Multi-  Microcomputer 

• Communications  between  processors 

• Protocol 

» Distributed  Systems 
° Standard  Bus 

Group  5 

° Functional  Requirements  for  Microcomputer  Control  Systems 
° Cost  Benefit  on  Microcomputer  Application  Systems 
° Limits  of  Microcomputer  Application 

° Developments  and  its  Tools  on  Bit  Slice  Microcomputers 
Group  fi 

Evaluation  on  Microcomputer  based  Products 


Preliminary  Working  Paper  for  ?MD  Microcomputer  Meeting  (Jan.  11,  19711) 

Koji  Yada 

Microcomputer  Working  Group 
IPW-J 


1.  Microcomputer  Development  Technology 

° MDS 
° PL/M 
° Emulator 

° Cross  and  Self  Software 
° Second  Source 
° Interface  Changer 
° Productivities  of  Software 
° Problems  on  Various  Microprocessors 

° Development  Tools  and  Production  Tools  for  Microcomputer  Based 
Products 

° Documentation  for  Microcomputer  Systems 

2.  Debugging  Tools 

° I ogic  Analyzer 
° Micro  Analyzer 
° Consol  t 

° Portable  Maintenance 
° Software  Debugger 
° Simulator  for  real  time  systems 
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The  ordinary  people  in  their  daily  life  had  very  few  contacts  with  the  large- 
scale  conventional  computers  before  microcomputers  appeared.  Microcomputers 
changed  this  situation.  Because  microcomputers  have  two  advantages  which 
the  large-scale  computers  do  not  have:  handiness  and  low  price.  This  change  is 
due  to  the  development  of  central  processing  unit  which  is  included  in  a micro- 
computer. Anyone,  regardless  of  age,  can  not  only  buy  a microcomputer,  but 
also  can  develop  creativity  through  building  and  using  microcomputers. 

Accompanied  with  the  development  of  microcomputer,  the  need  of  such 
an  opportunity  has  been  increasing  where  many  .Japanese  can  begin  studing 
microcomputer,  and  Japan  Microcomputer  Club  was  established  on  1st  of 
December,  1976,  and  received  a lot  of  approval. 

Japan  Microcomputer  Club  now  has  a membership  of  about  1,  200. 

Microcomputer  News  are  planted  bimonthly  in  English  and  they  are  sent  to  U.S. 
Microcomputer  Symposiums  are  held  on  every  Saturday.  There  are  40  to  110 
members  attend  every  symposium.  It  is  held  not  only  for  the  members  but  also 
who  attends  the  symposium.  Japan  Microcomputer  Club  includes  several 
committees;  Editorial  Committee  make  'Microcomputer"  magazine.  This  magazine 
has  been  an  organ  of  Japan  Microcomputer  Club,  but  now  it  is  expected  to 
extend  its  service  by  making  an  organ  to  a microcomputer  technical  magazine 
which  includes  articles  of  assembling  microcomputers. 

Reserch  and  Investigation  Committee  plans  to  hold  regular  seminars,  special 
seminars,  and  exhibition  of  member's  works  approximately  30  - 40  times  a year. 
Microcomputer  Standardization  Committee  holds  technical  investigation  of  Audio 
cassette  standard,  making  reference  to  Kansas  City  standard.  It  is  expected 
to  be  of  service  to  members  for  exchanging  microcomputer  programs  and  data. 
Microphotogram  Library  Committee  purposes  to  facilitate  exchanges  of  programs. 
Microcomputer  Contest  Committee  already  held  an  exhibition  of  computer  works 
and  contest.  It  helped  to  participate  in  'Business  Show'  and  'Microcomputer  Shos'. 
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Microcomputer  F'lngineer  Examination  Committee  purposes  to  examine 
microcomputer  engineers  and  technicians  in  basic  techniques  and  knowledge. 
Microcomputer  Organization  Committee  is  established  as  a branch  of  Japan 
Microcomputer  Club,  in  order  to  promote  communications  among  the  local 
members. 

Microcomputer  Planning  Committee  plans  an  inspection  trips  to  universities 
and  manufacturers, and  exhibitions  and  overseas  investigation  group  trip  are 
planned. 

Also,  there  is  a Microcomputer  Laboratory  which  offers  a place  for  exhibitions 
of  original  works,  and  for  work  shops  to  members  of  the  club. 

So  far,  several  microcomputer  research  seminars  have  been  held.  They  are 
divided  into  microcomputer  regular  seminars,  special  seminars  and  presentation 
of  microcomputer  researches.  'Microcomputer  Circular'  magazine  is  used  as 
a source  material  for  microcomputer  research  seminars. 

1 hope  for  development  of  microcomputer  technique  in  Japan  in  future  and 
it  will  make  Japan's  microcomputer  technique  firm  and  well  established. 
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Technical  Trends  of  Computing  Instrumentation 


Koji  Yada 

Electrotechnical  Laboratory 

5-4-1,  Mukodai,  Tanashi,  Tokyo,  Japan 


1 Introduction 

Today,  various  kinds  of  computers  such  as  micro,  mini,  and  large  scale 
have  been  occupying  the  important  parts  in  instrumentation  systems;  e.g. 
computer  supervision,  automation,  and  rationalization  have  took  the  pluce 
of  time  consuming  measurement  by  man  power.  Consequently,  scientists 
and  engineers  can  have  much  time  for  their  creative  works. 

One  of  the  advantages  that  a computer  has  but  a man  does  not  is  its  reliability 
for  continuously  repeated  tasks,  which  enables  adjustment  and  measurement 
of  the  instruments  to  be  executed  in  fixed  order  and  in  high  quality.  The 
most  important  feature  of  the  instrumentation  system  using  a computer  is 
its  flexibility  required  to  modify  and  to  exchange  the  components  frequently 
aiming  a better  system  construction. 

It  was  natural  in  such  circumstances  that  the  Computer  Instrumentation 
Committee  ( with  Professor  O.  Nishino  of  Kogakuin  University  in  the  chair  ) 
started  its  activity  of  investigating  instrumentation  using  computers;  e.g. 
definition  of  the  concept,  movements  for  standardization,  new  sensors  and 
component  computers,  program  languages,  and  software  systems  and  networks. 
Computing  Instrumentation  Committee  has  three  subcommittees,  which  are 
CAMAC  Committee  (Chairman;  Professor  I.  Miura  of  University  of  Tsukuba  ), 

Phisico  - Chemical  Instrumentation  Committee  ( Chairman;  Dr.  N.  Ogita  of 
Physical  and  Chemical  Research  Institute  ),  and  Applied  Instrumentation 
Committee  ( Chairman,  Dr.  K.  Sakurai  of  Radio  Electronics  Division, 

Electrotechnical  Laboratory  ) ( Fig.  1 ). 

Li 


We  will  cover  the  general  technical  trends  of  computing  instrumentation 
through  the  activities  of  those  subcommittees. 

One  of  the  major  goals  of  computing  instrumentaion  is  standardization; 
i.  e.  to  establish  the  common  software  which  enables  the  experimental  and 
measuring  instruments  to  be  connected  directly  with  any  computer. 

These  efforts  for  standardization  have  been  made  especially  in  the  field  of 
software  and  interface,  IEG,  CAMAC,  and  ISO  have  contributed  to  standardiz- 
ation of  real-time  languages. 


( 1 ) CAMAC  Committee 

* Connection  with  United  States  and  Kurope 

* Consolidation  of  CAMAC  materials 

* Publication  of  CAMAC  newsletters 

* Investigation  into  micro  CAMAC’  ( intelligent  CAMAC  ) 

* Investigation  into  real  - time  HAS1C 


( 2 ) Physical  and  Chemical  Instrumentation  Committee 

* Investigation  into  LA  technology 

* Investigation  into  precise  instrumentation  technology 

* Investigation  into  Smart  measuring  instruments 

* Investigation  into  measurement-purpose  interfaces 

* Investigation  into  measurement-purpose  softwares 


( 3 ) Applied  Instrumentation  Committee 

* Investigation  into  public  utility-instrumentation  system 

( electricity,  gas,  and  water  ) 

* Investigation  into  environmental  instrumentation  system 

* Investigation  into  traffic  instrumentation  system 

* Investigation  into  instrumentation  against  disasters 

* Investigation  into  medical  instrumentation 

* Investigation  into  atomic  energy  instrumentaion 


Fig.  1 Computing  Instrumentation  Subcommittees 
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2 Computers  for  computing  instrumentation 
( 1 ) Rasic  feature 

The  basic  feature  of  the  computer  required  for  computing  instrumentation 
is  capability  to  monitor  and  control  the  measuring  instruments  in  real-time 
i environment;  i.e.  facility  of  a real-time  program  that  enables  a computer 

which  is  connected  on-line  with  measuring  instruments  to  collect  data  as 
results  of  experiments  from  sensors  and  analyze  the  data  to  generate 
control  singals. 

I 

( 2 ) Types 

Mini  computers  have  been  most  commonly  used  for  computing  instrument- 
ation for  its  real-time  feature.  However  for  its  remarkable  development  in 
technology,  microcomputers  may  take  the  place  of  minis,  In  computing 
instrumentation,  it  is  desirable  to  build  each  experimental  and  measuring 
instrument  to  be  organized  as  a dedicated  network  under  control  of  a computer. 

For  this  purpose,  large  scaled  computers  must  be  investigated. 

(3)  Mini  computers 

Mini  computers,  along  with  micros,  have  been  on  the  rapid  way  of  the 
capacity  expansion.  For  the  instrumentation  purpose,  mini  computer  tends 
to  be  used  as  a controller  for  large  experimental  equipments,  or  as  a 
switching  computer  for  communication  control.  One  of  the  mini's  features 
is  its  excellency  in  cost  performance  in  comparison  with  large  scale  computers, 
which  enables  to  build  a computer  system  as  a feature's  unit  according  to 
its  purpose.  1 

( 4 ) Microcomputers 

Micros  are  most  expected  for  computing  instrumentation  because  of  its 
decreasing  cost  and  progressing  technology.  Micros  can  be  built  in  a smart 
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channel  couple  adopter' 
eomnumieation  control  unit 
network  control  unit 
device  coupler 
experimental  instrument 


g.  It  System  Organization  of  Computing  Instrumentation 


- 345- 


instrument  or  an  intelligent  measuring  instrument,  or  used  as  a dcviee 
coupler  for  connection  of  measuring  instruments  with  a mini  computer  or 
an  intelligent  terminal. 


3 Computing  instrumentation  and  networks 
( 1)  System  organization 

Computing  instruction  systems  are  constructed  with  defferent  components 
connected  with  each  other,  which  enables  efficient  use  of  a system  resource. 
Using  a large  scale  computer  for  these  systems,  the  better  system  develop- 
ment tools  can  be  gained;  e.  g.  large  scale  files  can  be  used  for  data  retrieval, 
and  an  exclusive  file  machine  can  be  accessed  as  a distributed  file. 

Fig.  3 shows  how  the  computer  center  and  each  experimental  instrument 
interface  at  the  research  device  couplers  to  exchange  data  via  datarhigh  ways, 
and  communicate  each  other  from  remote  locations  through  modems. 

( 2 ) Device  couplers 

A device  coupler,  so  called  Research  Device  Coupler  ( RDC  ) by  IBM  Corp.  , 
is  an  instrumentation  interface  for  experimentalists  using  an  interactive 
terminal-purpose  system.  It  is  a box  which  can  be  put  on  a 19  inch-wide 
shelf,  and  can  envolve  8 hardware  modules  which  are  for  system  communication 
digital  and  analog  input/output,  program  storage,  and  tape  storage.  Each 
module  can  be  combined  with  any  other  except  a system  communication 
module  with  a progeam  storage  module. 


j 
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(3)  Intelligent  station  for  instrumentation 

One  of  the  features  required  for  instrumentation  in  scientific  and 
technological  laboratories  is  flexibility  of  the  measuring  instruments. 
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In  measurement  of  unknown  phenomena,,  the  procedure  is  so  unstable 
that  different  methods  of  measurement  must  be  taken  in  order  by  comparing 
the  new  result  with  the  former  ones  until  satisfactory  data  can  be  gained. 

With  a conventional  hardwired  system,  it  is  not  enough  to  meet  the 
measurement  purpose  of  the  basic  experiment,  even  though  the  system  may 
be  designed  in  consideration  of  various  phenomena. 

If  you  use  a recent  microprocessor  fixed  in  the  measuring  instrument,  the 
system  will  gain  a lot  of  flexibility  under  program  control. 

There  is  a movement  for  standardization  of  programming  ( structural  program- 
ming ),  but  the  personal  programs  written  with  free  ideas  might  seem  more 
attractive. 

A small  sized  hardware  is  most  desirable  for  a measuring  instrument. 

Those  instruments  are  not  constantly  used  in  laboratories;  i.  e.  productivity 
or  cost  performance  is  rather  low.  To  supplement  this  deficiency,  conventional 
method  is  a proper  design  of  a measuring  instrument,  which  can  measure 
and  process  data  within  predictive  phenomema.  Hut  whether  a phenomenon 
is  without  range  of  prediction  or  an  error,  there  is  no  way  of  recognition  or 
even  it  can  be  easily  neglected.  Recent  method  of  combining  a microprocessor 
with  floppy  discs  made  it  possible  to  construct  a simple  hardware  which  can 
store  data  raw. 

An  intelligent  station  for  instrumentation  is  a project  which  uses  a compatible 
microprocessor  in  an  experimental  instrumentation  system  for  general 
purpose;  it  can  convert  data,  check  formats,  and  adjust  signal  levels  in 
order  to  collect  any  kind  of  data  from  any  kind  of  measuring  instruments. 
Farther,  it  is  aimed  to  hold  an  interface  for  the  practical  use  of  a large 
scale  computer's  source,  to  have  local  files  for  raw  data  storage,  and  to 
undertake  some  of  the  tasks. 
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(4)  Smart  measuring  instrument 

To  connect  with  a computer,  a measuring  instrument  conventionally 
needs  a research  device  coupler  or  an  intelligent  station  for  instrumentation 
as  a go-between.  Hut  by  fixing  a microprocessor  in  a digital  multimeter 
or  as  oscilloscope,  it  is  being  possible  to  connect  those  instruments 
directly  with  a computer. 

Smart  measuring  instrument  is  an  internally  programmable  product, 
different  from  conventional  which  requires  to  be  programmed  by  an 
external  computer.  Consequently,  it  lias  been  possible  to  set  up  values 
through  keyboards  and  to  make  various  measurements  by  programming  the 
measuring  procedures  instead  of  conventional  way  of  handling  disgusted 
numbers  of  buttons  on  the  control  panel. 

A smart  scope  is  an  oscilloscope  with  a microprocessor  and  a LTD  display 
fixed  inside,  which  can  digitally  read  some  kinds  of  waves  directly.  Also 
the  logic  scope  is  on  the  way  of  development.  It  contains  two  analyzers; 
one  is  the  logic  analyzer  which  can  recognize  an  error  whether  logical  or 
electrical  by  measuring  the  functional  state  and  representing  it  with  0 and 
1;  the  other  is  the  timing  analyzer  which  investigate  the  I/O  wave  patterns 
of  up  to  12  devices  by  displaying  them  on  the  CRT  screen  as  standard 
timing- diagram. 

( 5 ) Data  highway 

A data  highway  is  a group  of  lines  connected  with  CPU  via  some 
terminals;  which  can  transmit  more  than  one  data  by  time  sharing. 

A data  highway  makes  wiring  cost  down  and  system  extention  simple; 
the  technique  is  suitable  for  distributed  systems  using  a mini  or  a micro 
computer;  connecting  a computer  and  a terminal  by  data  highway,  the  cost 
is  far  less  expensive  than  connecting  directly  by  numbers  of  wires. 
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•1  ('output  i n j\  Instrumental  ion  and  Interface 
( 1 ) Actual  interfaces 

Interfaces  are  located  between  measuring  iust  laments  and  computers 
and  consist  of  elect ronics  and  sollw arrsi,  II  is  desirable  that  thost'  interfaces 
can  connect  any  instrument  with  any  computer.  However,  as  a result  ol 
remarkable  development  in  various  techniques,  they  have  not  yet  been 
standardized.  Instead,  device  couplers,  interlaces  plus  variable  features 
are  under  consideration. 

There  are  some  methods  of  interlacing  or  connecting  instruments  to 
computers;  e.  g.  parallel  I/O  buses  with  serial  cables,  general  purpose 
teletype  interlaces  with  serial  ASCII,  CAMAC  interfaces,  and  HI’-IH  tele 
type  interfaces.  Especially,  CAMAC  and  IIP  111  interfaces  are  most  notieahle 

(2  ) CAMAC  vs  111’  III 

CAMAC  is  suitable  for  more  kinds  of  devices  from  farther  destances 
with  higher  speed  for  transmitting  larger  volume  of  data  than  111’  IH. 

However,  CAMAC  is  more  expensive  than  111’- lit  because  oT  its  necessity 
for  a crate  and  a controller,  decently’,  economy  crates  with  1.1  slots  ami 
microprocessor  based  controllers  are  popular  to  sell. 

Ill’-llt's  merits  are  its  simple  Iti-wii  e interface  and  simple  instruction 
system.  Kor  connecting  a specific  device  which  does  not  tit  HI’-IH,  redesign 
of  interlace  circuit  is  the  most  simple  method. 

CAMAC  to  III’  lit  interface  is  possible  if  surrounding  a CAMAC  serial 
dalaway  all  over  the  laboratory  and  setting  up  a lll’-llt  device  loop  in  each 
experimental  room  for  managing,  instruments. 


!>  Computing  Instrumentation  and  Software 

(I)  I’rogram  languages  for  computing  i nst rumentation 

As  a language  for  computing,  instrumentation,  only  assembler  language 
is  m use.  I lowever,  development  of  high  level  languages  as  real  time 


FORTRAN,  real-time  BASIC,  and  real-time  API.,  as  well  as  program- 
oriented  language  as  PERI-  (Process  and  Experimentation  Real-time 
Language  ) for  computing  instrumentation  is  now  expected. 

As  the  real-time  OS,  either  a specific  OS  or  a general-purpose  OS  is  used 
according  to  the  instrumentation  types. 

( 2 ) Real-time  BASIC 

Real-time  BASICS  are  implemented  by  some  companies  as  DEC,  HP, 
and  Takeda  Riken.  Investigations  into  standardization  of  Real-time  BASIC 
are  made  by  IPW  ( International  Purdue  Workshop  ) in  Purdue  University, 
United  States,  and  Standard  Committee  for  Industrial  Computers  ( chairman 
Professor  Mitsuru  Terao,  University  of  Tokyo  ) of  JEIDA.  CAMAC  has 
announced  a real-time  BASIC  oriented  for  CAMAC,  which  is  an  extensive 
version  of  usual  BASIC  where  real-time  features  as  process  variable 
operation,  intei'rupt  operation,  bit  patterns,  and  logic  operation  are  added. 
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Abstract 

This  paper  surveys  the  most  recent  (2nd 
quarter,  1977)  status  of  Japanese 
microprocessors,  including  original  and 
second  sourcing.  Nine  companies  are 
producing  about  twenty  kinds  of 
microprocessor s . The  profile  of  the 
original  products  and  the  status  of  the 
second  sourcing  are  introduced. 

1.  INTRODUCTION 

This  paper  is  based  on  the  materials  in 
the  Microcomputer  Handbook  edited  by  the 
first  author  and  will  be  published  soon 
in  Japanese  language. 

Roughly  speaking  of  Japanese 
microprocessors,  the  following  three 
points  will  be  cited:  (1)  many  original 
microprocessors  in  the  field  of  low  end 
microcontrollers  (4  bit,  most  of  which 
are  single  chip  microcomputers J and  high 
performance  general  purpose 
microprocessors  (16  bit),  (2)  second 
sourcing  of  the  Intel  8080A  and  Motorola 
6800  tamly  in  the  field  of  8 bit 
general  purpose  microprocessors,  (3)  no 
original  nor  second  sourcing  in  the 
field  of  bit  slice  microprocessors. 

2.  4 AND  8 BIT  ORIGINAL  MICROPROCESSORS 

Table  2.1  and  2.2  show  4 and  8 bit 
microprocessors  in  Japan.  They  are 
divided  into  two  groups,  air.glc  chip 
microcomputers  and  others. 

2.1  H.MCS4  5A/B 

Hitachi  announced  a s.nglc  chip 
microcomputer  HMCS45A/B  (Fig-  2.1). 
H'.Cbl.jA  is  the  basic  type,  packaged  in 
54  pin*  flat  package.  NMCS45B  is 
packaged  m 42  ptr.  DIP.  Users  can 
define  optional  instructions  in  addition 
to  a standard  set  of  instructions.  An 
evjlu.H  inn  board,  H45KV00,  which 
includes  an  evaluation  chip.  Mb J8600I’. , 
is  provided.  IUXS45A  has  16  discrete 
I/O,  six  4 bit  parallel  I/O.  two 
maskable  interrupts  Internal  ROM  has 
2Xxl0  bits,  and  if  otter*  wish  more, 
address  space  is  expandable  to  4Kxl0 
bits,  adding  external  (P)HOM  chips.  It 
has  a twelve  bit  timer  with  interrupt 
capability  and  a display  decoder  with 


five  bit  input  and  eight  bit  output 
which  can  be  defined  by  the  user. 


INT  TEST-  I'ofSP 

1?  i » 1 


DISCRETE  R,0~Rij 
>/0  (i.0,1,— ,5) 

J/0 

CGR : internal  clock  generation  roouct 
A : ACC 
D : sub  ACC 

X : 4 bit  higher  address  register  for 

RAM 

Y : 4 bit  lower  address  register  for 

RAM 

gpy!]4  bit  working  reqisters 
Ri  : data  I/O  register 

Fig.  2.1  HMCS  45B 
2.2  MM 1400  SERIES 

Matsushita  announced  a series  of  4 b.  t 
microprocessors,  two  of  which  are  sirulo 
chip  microcomputers.  They  arc  cxp»  ted 
to  be  used  for  home  electronics  ana 
other  consumer  products. 

MN 14  00 

MN 14  00  is  a single  chip  N**OS 
microcomputer,  including  ROM,  HAM, 

I/O  linos,  clock  ger.er.it or  and  8 bit 
binary  counter  (Fig.  7.2 I.  Its  29  r > 
lines  include  2 sense  inputs,  ? ; 

4 bit  parallel  input  ports,  12  duo*  tie 
inputs,  4 bit  parallel  o.iMait  n,  r>  J .«n  6 
bit  parallel  output  port  with  IMV 
Clock  generator  has  tuo  rodeo:  calf 
oscillation  by  external  RC,  or  ac-epiirg 
external  clock  pulses. 
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A R l 

POIT  fO«T  PORT 

PS  : program  st.it  us 

SF  i terse  flag 

CSLCT  : mode l tense  or  count)  select  for 
SNS  i 

SNS|,j:  sense  inputs 

Fig.  2.2  mn 1400 


KNH02 

MN  14  0 2 is  s 4 bit  Single  chip 
microcomputer  and  is  a smaller  version 
of  MN1400.  The  numbers  of  instructions, 
pins,  output  pot ts  and  the  capacity  of 
ROM  and  RAM  are  smaller  than  those  of 
MN  14  00.  The  counter  is  not  included. 

MN 14  9 8 

NN14S8  is  a microprocessor  without  ROM 
pait  of  MN 1400  and  is  suitable  for 
products  of  small  quantities. 

MN 1499  Is  an  evaluation  chip  for  MN1400 
and  MN 1402.  The  configuration  is  the 
same  as  that  of  MN'1400  with  the 
exception  that  it  has  no  ROM  and  has  bus 
for  instruction  memory  and  SYNC,  READY 
lines  and  display  decoder  is  to  be  added 
to  the  chip. 

2 . 3 pCOM40  Senes 

NEC  introduced  seven  kinds  of  4 bit 
microprocessors,  4,  41,  42,  43,  44,  4S, 
end  4$. 

WCOM4 

it  COM4 , introduced  in  Aug . 197  J,  was  the 
first  N ‘ ’.0 : . Microprocessor  in  the  world. 
If  is  a 4 bit  mi-  foprocessor  in  .*4  pin 
n;r . It  bas  sep.iiato  addie-.s  and  data 
bus  and  st. it*  ‘top  pin.  Eon  bit  I/O 
inter  t ace  (y  i'll  75 20  01  is  provided. 

I COM4? 

uCOM4 ' is  e 4 bit  s:n«ila  chip 
i*>.  it  1 1 . imimt  »•  r and  . s dove  loped  for 
systemn  »r  which  IICD  arithmetic  if.  the 
mn  i n opei.it  ion  such  as  ECR,  electronic 


weighing  measure,  snd  desk  top 
calculator  with  printer.  Ports  K,  S,  U 
end  R aie  respectively  assigned  to  m*v 
input m (K),  I/O  port  for  auxiliary  RAM 
(S>,  key  output  tor  key  scanning  and 
display  segments  (l1)  , and  signals  for 
digits,  printer  hammer  drive  and 
auxiliary  RAM  address  ( R ) . Hardware 
simulator  (wPP5i>5D)  is  provided  for 
system  development. 

PCOM43 

!iCOM4  3 is  a 4 bit  single  chip 
•ic r ocomputer  designed  for  the  control 
of  devices  such  as  copying  machines, 
facsimiles,  sewing  machines  and  nding 
mahines  (Tig.  2.3).  It  has  a 12  bit 
timer  and  an  Interrupt  lire.  Bit 
manipulating  instructions  and  flexible 
data  pointer  make  I/O  facilities 
powerful.  Hardware  simulator  lyFDSSo) 
ia  provided. 


H GF  EDC0A 


CF  : carry  flag 

CF':  carry  save  register 

DAR : data  address  reg inter 


Fig.  2.3  i»COM4  3 


2.4  SM  Series 


Shaip  is  producing  three  typos  of  single 
chip  microcomputers. 


SM  1 is  for  systems  with  keyboai  1 input 
end  numeric  display  out  out.  tt  h'* 
throe  sets  of  input  terminals  i'.Nl  , k-  ? 
and  KF . eight  segment  output  *»ei  m ’i, 
SI  to  S8  . and  nine  tir.in  outp  -.t 
terminals,  Tl  to  T9.  Segment  outputs 
can  dt  i ve  plasma  or  l.r0  dsspl.iv 
directly.  It  also  includes  a so  ;.vnt 
dci  cider  . 

SM  2 

SM  2 is  a 4 hit  single  chip 

mici Ooouputei  for  control  a plii  it  iO"i 
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such  as  <?«.  sk  top  calculator*  with 
printer,  printer  controllers,  cash 
r < g 1 seer  * . vending  machines  and  hone 
elec*,  onics  (Fig  2.4).  It  has  various 
I/O  emunals.  Five  input  terminals 
( K.'« t , K\?,  K r.  AK.  TAD ) for  synchronox:s 
inputs,  three  input  tcrnin.iis  (n,  5 , V) 
for  asynchronous  inputs,  4 bit  parallel 
output  terminal  (F) , seven  output 
terminals  (Si  to  S 7 ) for  timing  signal 
outputs,  sixteen  output  terminals  (Wl  to 
UlM  *iam  a shift  register  controlled  by 
programs . 

SN-J 

SM-3  is  a general  purpose  4 bit  single 
chip  r i crocorputer . in  a 60  pin  OIL 
package,  for  applications  such  as  cash 
registers,  desk  top  calculators  with 
printer,  microwave  oven  controllers, 
sewing  nachir.es  and  POS  terminals.  I/O 
terminals  of  this  chip  include  eight 
input  terminals  and  four  I/O  terminals 
for  data  I/O,  four  parallel  output  lines 
and  ten  output  terminals  for  strobing. 

A discrete  output  and  twenty  two  general 
purpo*e  output  terminals,  seven  of  which 
can  be  used  as  a segment  driver,  ere 
also  included.  Hardware  emulator  is 
aprovideJ • 

2.4  Microcontroller  and  TLCS-41 
T3444 

T3444  is  a fast  Sr!0S  microcontroller, 
vith  8 bit  data  bus,  driven  by 
picrO'imtruct  ions  of  24  bits  and  624ns 
cycle  tra  iFiq.  2.5).  It  is  especially 
suited  for  the  control  of  high  speed 
devices,  such  as  floppv  disks  ar.d 
digital  cassettes,  although  it  is  also 
fit  to  rfdiun  or  low  speed  controllers. 
The  control  ROM  (256x24  bit)  is  mask 
pro? Tamable . Lsir.g  this  chip,  Toshiba 
his  J.  vo  lopped  two  kinds  of  cor.t  rol  Irrs  , 
one  for  floppy  disks  and  one  for  digital 
■«i5«  * rei,  which  can  be  used  as  the 
; or  oral  I/O  of  microcomputers  such  as 
7os*iuJ  TLCS-12A. 


’ t *.  m.cro  instruction  includes  (1) 
son  1 1 input  and  shift,  (2)  cyclic  shift 
•,.»  /ogs3t«,ru,  X/Y  RAM  and  C 
• ••fjts*.  r , (3)  cyclic  code  op*r,ltion'  ( 4 ) 
« ••  •.!  t*  ar sfer  between  Y RAM  ar.d  B 
r*gi**»rs.  Bonce  this  processor  has  the 
: • i l 1 1 y of  fast  data  handling  such  as 
(1»  r-  ' i i a 1 - para  1 lei  transformation  of 
•roit  ir  output  data,  (2)  cyclic  code 

• .-n  and  chocking.  (3)  data  format 
rdM  a -d  chocking.  (4)  data 
...  f ?»-m;  and  linking,  (5)  control  of 
dovice  mechanics. 


rrc<-u 

his  is  a 4 bit  \:-.OS  single  chip 
r u ro  *cTui:ter . It  is  fit  to  the  devices 


DOF:  discrete  ouptput  flag 
^ '] input  latches 

F : latched  output  from  f>CC 
W : serial  to  parallel  conversion 
register 

OCF : output  contiol  flag 


AN,  : 
KN,  : 
KF  : 
AK  : 
TAn  : 


asynchronous  input  latches 

(synchronous  1 bit  input  ports 
strobing  signal 


Fig.  2.4  SF-2 


which  require  key  ar.d  display  operations 
like  F.CR . It  includes  key  and  display 
controller  which  enables  control  or  l)ie 
64  push  keys  and  lb  lock  keys  a*  the 
same  time,  and  display  cf  lb  digits  and 
16  LEDs  at  the  same  time.  Its  b7 
instructions  include  the  ar it  hr  otic 
operation  of  up  to  16  digit  BCD  ar.d 
block  transfer  of  o to  1 6x4  bit  data. 
External  and  key  interrupts  ate 
acceptable.  Restart  tram  the  arbitrary 
address  is  pv>ssible.  Interlace  Chios 
for  printer  control,  T3*>38  aid  734  73, 
are  available. 

3.  12  fc  16  BIT  ORIGINAL  MlCROPROCrsSOf.S 

Table  3.1  shows  four  kinJs  of  12  and  lb 
bit  Japanese  original  micr opiocuxsor* . 

3.1  uCOM-16 

U COM- 16  is  a 16  bit  V S r.’irror  ocssor 
controlled  by  micro- ins?  ruct  i .•ns  (Fsg. 
3.D.  The  CPU  is  co"  posed  of  th.reo 
component o : RALU  (Register  and 
Arithmetic  Logic  Unit), 


i 


i 


J 


I 

i 


Rt.Ri  receiver  buffers 
K,  ,W|  : worVir.q  registers 
N : begat  i v«*  f lag 

C : curry  flag 

T : traiu..*uttor  buffers 

Z : zero  tlaq 

Fig  . 2 . 5 T3<44 


To  Memory  I/O 


F»q.  J.l  nCOM-lb 

system  diagram 


Hi.  lOM-  '.tructH'.i  tin.  and  Control 
Chir  It  »h  suitable  l»*r  onu  1 .it  ion  of 
lb  bit  piocessor  or  designing  Spe- 
pvi  w or.put  or  •.  KAI.U  t ip  cont  i.r.s 

IS  general  purpo  ;c  registers  ur.d  ALU, 
c»  • : ; '’l  led  by  rrnrr  *-  inst  rue  t ions  . 
Control  chip  coni.’.  us  a mapping  array 
s*b  1 1 > tan  dec  »do  1 00 


micro-instx actions.  Users  can  define 
their  assembler  level  instructions  by 
spool  tying  the  mapping  array  snd  control 
ROM . 

3.2  L-I6A 

L - 1 6 A is  a 16  bit  N.VC'J  single  chip 
microprocessor  introduced  in  19  7S  (Fig. 
3.2).  In  addition  to  the  powerful 
mini  errput  or  - 1 l Vo  ln»i  : i.  •*  :on  . , it  has 
instructions  tor  byte  and  digit 
operations.  Memory  capacity  is  64K  '-id 
(12  HK  by?  e).  fjn  I/O  interface  chip- 
•re  UMAC  (DMA  Controller)  and  SCA 


SCA  : Subchannel  Adapter 


Fiq  . 3.2  PANMACOM  1.  If  A 

1.51 1 system  configuration 


i 
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(r*  1 ’ w a . r «» 1 Adapter),  which  make  total 
‘ -oact  . {)-'L\C  hat.  two  mo  Jos 

! n • t ' ~.\k-  12 00k  word  see)  and  interlace 
a ( ■ 'k  to  lOOK  word < see)  • tty  to  snd 
• «.».  ? t-  r.irr  is  provided.  SC  A is  a 
~ ah  1 1.*  8 bit  parallel  I/O 
interface  chip  with  four  input  nodes  and 
tv.  nut  pat  modes:  direct  input,  strobed 
in;  it,  pilse  input,  interrupt  input, 
d • : c?  output  a id  pulse  output, 
f'd’u  uf  and  h irdwure  for  channel 
•'  to  the  minicomputer,  PAYAFACO.M 

l c » ' * "7,  are  available  and  provide 

rut i4  Tuer. » hierarchy  systems. 

.1.3  TICS-12A 

Tl.CS-1  ?A  is  s 12  bit  NMOS  mcroprocr Jior 
with  SV  single  power  supply  (Tig.  J.J). 
This  i*  a revised  version  of  its 
pro  -.e :cssor , TLCS-12,  which  was 
introduced  an  1974.  It  is  controlled  by 
microprogram  internally,  and  ha* 

•tu»t.ply  and  Divide  instructions.  Its 
lrer-al  eight  word  general  registers 
can  be  created  as  memories  located  at 
the  tep  of  the  address  space.  It  has 
powerful  interrupt  capability:  # 
terminals  for  interrupt  requests. 


BUS*-' MS, , 


1C  : t iring  control 

!*•  * run  or  stop 

0*  : or,r..ic  o,  halt 

i*i  ,C  c kjm  bus  status 
f c trol  mo-1'  s from  console  panel 

. : v tern*!  cl-«k  or  internal  clock 

i per.  t m.j  spe-  1 control 
»-  ce.u  ra!  roqisirrs 

.]  tki-.j  t -jisUts 


Via  3 . 1 TI.CS-12A 


maskable  vectored  inter  ‘s,  and 
alterable  interrupt  pr-.eiity.  Clock 
generator  is  included  m the  ct  ip  with 
internal  !tC  and  a 1 vO  can  be  controlled 
by  an  external  Xl.il  or  P " . 

3.4  TO  Ml  AC- 4 OL 

Th . s is  an  I.M  vet  non  -f  16  bit  Toshiba 
mini,  'mputer.  TO.'-'V.C  - 1 -V  . TOf*l»Ad  4df  is 
CO"*;»l  et  e 1 y software  h«r  ...are  ccmptlible 
with  the  m* e i:  -mu* er . Users  ran  u -e 
pbwet  tul  • >f  tv  are  pack  : :«•*  su-h  as  high 
level  languages  (por:  can  lv,  CO’hiL, 
PL/40),  POS,  POPS  (Process  Operating 
System),  FTS  (Free  Time  System',  TCS 
(To  le -Commun  icat  ion  System),  HL.S 
(Hierarchy  Service  System)  and  TVCS-4C 
(Toshiba  Minicomputer  Complex  System) 
which  supports  multiprocessor  sy.tem  for 
real  time  control  of  up  to  5 CPUs  as 
well  as  various  peripheral  devices.  It 
also  has  float  inq  point  and  double 
precision  arithmetic  instruct. ons  as  a 
standard  feature.  The  lO-xlO"  CPU  board 
contains  an  ACU  (Arithmetic  and  Control 
Unit),  five  BCU  (Bus  control  Unit)  and 
microprogram  ROM. 

4.  SECOND  SOURCING 

As  mentioned  in  Section  1,  Japanese 
semiconductor  manufacturers  second 
source  Intel  HCflOA  and  Mctorolla  6800 
family.  Some  produce  fully  compatible 
ones  and  the  others  upjrided  ones  (Table 
4.1)  NPC  and  Hitachi  have 
erosn-l  ic.-nsed  with  Intel  and  Motorola, 
respectively,  concerning  microprocessors 
and  related  technology. 

5.  TRAINING  KITS 

One  of  the  mesf  remarkable  recent  everts 
on  the  microcomputer  industry  lias  been 
the  advent  of  training  kits.  TK  ?0  by 
NEC  was  the  first  one  which  appeared  in 
1976.  The  success  of  the  7X-80 
stimulated  other  microprocessor 
manufacturers  to  supply  training  kits 
for  users.  Table  5.1  shows  the 
specifications.  Common  features  are  an 
follows:  (1)  not  expensive  (about 

¥100, OCO  or  $<70)  l ? ) has  basic  keyboard 
and  display  (usually  a tew  tens  of  kiyu 
and  7 segment  LCDs)  (H  has  basic 
monitor  program  (4)  assures  u:o  of  audio 
cas  tto  ler  backup  (5)  complete  not  ot 
manuals  or  textbooks. 

TK  - 30 

Tx  80  by  NX  has  ♦.  -ntv  five  keys  .vrJ 
eight  never -segment  display*  to  give 
users  programming  fuci’itv  by 
he  ,.i  !co  ima  1 cedes.  T nr  train  features  of 
the  hardware  ate  C'o.l  and  LAIN ; . 

Battery  bac'  up  is  available.  A short 
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LK  I T 9 

LKIT  8 by  Fujitsu  is  • in'.nr  to  *IN-8  0 
w»*h  « major  differer.  t*  of  its 
processor.  The  console  bo:  rd  is 
separated  fr»>m  the  rain  t-nerd,  ard  can 
be  removed  when  it  is  nut.  necessary. 


LK  I '*-16 

LKIT-16  by  Panafacc-n  is  bused  on  L-16A 
which  is  a 16  bit  original 
mcroproresr.or  with  hi  jh  por'or'a-.cr. 

The  pri.*e  feature  IS  th.it  eu.'h  M-y  :>f 
its  keyboard  corresponds  to  a niduntS 
instruction  or  a mnemonic  rode.  Tsc  kit 
has  two  Staqes  of  boards:  the  keyboard 
and  the  rvain  CTU  board.  Audio  cassette 
interface  is  fully  provided  including 
built  in  connectors  to  the  tape 
recorder . 


Hb 8 /TP 

llo9/TR  by  Hitachi  is  the  neves*  and  one 
of  the  rost  useful.  It  has  a basic 
symbolic  assembler  as  veil  as  a monitor 
program  in  32K  bit  mask  ftOM,  and  also 
has  a compart  keyboard  and  a special 
display  terminal  on  which  ?6  alphabets, 
JO  digits,  and  12  other  characters  can 
be  input  or  output.  The  meaning  of 
"special"  is  that  each  of  48  characters 
has  it  a own  *ey  but  is  displayed  on 
usual  7 segment  displays  using  rather 
special  forms  of  characters  (r.<*e  Fig. 
5.1).  Add  it  ic  ul  point  to  be  noted  is 
the  facility  for  cassette  contiol  by 
relays.  This  enables  users  to  edit 
source  or  data  files  using  tw><  tape 
recorders  automatically  controlled  by 
the  microcomputer,  using  an  optional 
editor  program. 


:\cns 


1.  n.  Mori  (cd.),  Microcomputer  Far.dt 
(AsaVuro  Shoten,  To’.yo,  to  be 

publ : shed ) . 

2.  Manuals  of  correspond j -g  pr*  • < ■*.»  >r  ; 

Ar.  1 kits. 
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Jaoan  Microcomputers  Club  At  Its  Start 


By  Shigeru  Watanabe  (President) 
University  of  Tokyo 


Tiny  microcomputers  have  realaized  a human  dream. 
These  days  anyone  can  use  a computer,  which  was  out  of  reach 
several  years  ago.  Three  features  of  microcomputers , easy 
to  build,  cheap  to  purchase,  and  widely  applicable,  have 
attracted  young  generation  as  the  intellectual  "hobby". 

Japan  Microcomputer  Club  has  made  its  meaningful 
start  in  this  fall.  Microcomputers  are  now  available  not 
only  for  experts  but  for  anyone, anywhere  and  at  anytime. 

Since  first  introduced  into  Japan,  microcomputers 
of  American  birth  have  been  developed  in  Japan  and  many 
excellent  programs  have  been  created.  Everyone,  however, 
has  not  ever  dared  build  a computer  of  his  own. 

Popularization  of  microcomputers  has  made  it  possibl 
or  young  intellectuals  to  use  them  in  various  areas.  That  is 
every  amateur  computer  hobbyist  has  a chance  of  being  an 
inventor  of  new  and  first  products  of  the  world. 

These  invents  may  be  leading  lights  for  the  future 
of  ocr  country.  Through  our  Club,  we  hope  new  products  or 
techniques  will  be  announced  to  the  world. 
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Aims  of  Japan  Microcomputer  Club 
I 

It  is  the  club  for  amateur  computer  hobbyists 
who  are  willing  to  build  there  own  computers  and  obtain 
technical  information. 


I 


Activities 

(1)  Publication  of  Microcomputer  News 

(2)  Microcomputer  Symposium 

(3)  Microcomputer  Laboratory 

(4)  Observation  Study 

(5)  Microcomputers  Applications  Contest 
16)  Publication  of  Technical  reports 

(7)  Discount  services  of  Microcomputer  Products 

(8)  Investigation  and  Data  collection 


i 
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Ornanization 


President  : 

Watanabe,  Shigeru 

(University  of  Tokyo) 

Councilors  : 

Takahashi,  Hidetoshi  (Keio  Univ. ) 

Terao,  Mitsuru 

(Univ.  of  Tokyo) 

Nag  unto , Zin 1 oh i 

(Univ.  of  Tokyo) 

Moto'oka,  Tohru 

(Univ.  of  Tokyo) 

Ishii,  Takoir.oohl 

(Univ.  of  Tokyo) 

Umetani,  Youji 

(Tokyo  Institute  of  Technology) 

Aiiso,  Hideo 

(Keio  Univ. ) 

Ohkawa,  Yoshikuni 

(Univ.  of  Gifu) 

Yaita,  Tohru 

(Hose i Uni v. ) 
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Ikcno,  Shinichi 


Ohsuga,  Setsuo 
Yamamoto,  Kinko 
Ogita,  Naonori 


(Nippon  Telegraph  & Telephone 
Public  Corporation,  Musashino 
Electrical  Communications 
Laboratory) 

(Univ.  of  Tokyo) 

( JIPDEC) 

(Institute  of  Physical  & 
Chemical  Research) 


Managerial  Committee  : 


Chairman 

Watanabe,  Shigeru 

(Univ.  of  Tokyo) 

Vice-chairman 

• 

• 

Fuchi,  Kazuhiro 

(Electrotechnical 

Lab.  ) 

General  Affairs 

• 

Miura,  Hirofumi 

(Univ.  of  Tokyo) 

Secretaries 

Tohyama,  Takashi 

(Chiyoda  Chemical 
Engineering  and 
Construction  Co.) 

Secretaries 

Kamata,  Nobuo 

(Intel  Japan  Co. , 

Ltd.  ) 

Secretary  & 
Symposium 

Yada,  Koji 

(Electrotechnical 

Lab . ) 

Planning 

Hayashi,  Toyohiko 

/Visual  Information 
'System  Development 

Asson- 

Technical 

Reports 

Masada,  Eisuke 

(Univ.  of  Tokyo) 

Microcomputer 

Laboratory 

: 

Sato,  Keizaburo 

(The  Tokyo  Metropolitan 
Industrial  Technology 

Center) 

Qualification 

Test  for 
technicians 

2 

Narita,  Seinosuke 

(Waseda,  Univ. ) 

Microcomputer 

Contest 

2 

Sato,  Chikara 

(Ke io  Univ. ) 

Technical 

Observation 

Study 

2 

Nakanishi,  Toshio 

(Seikei,  Univ.) 

Microcomputer 

News 

Umeda,  Akira 

(Univ.  of  Tokyo) 

Public  Relation 

Fukuda,  Akio 

(CQ  Book  Co. , Ltd . 

) 

Overseas 

Shiina,  Takashi 

(SORD  Co. ) 

Secretaries 

Miyata,  Fumio 

(Univ.  of  Tokyo) 

Secretaries 

Fumio  Takamido 

(Tokyo  Management 

Association) 
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What  Docs  A Microcomputer  Mea n ? 

By  Koji  Yada 

Electrotechnical  Laboratory 

The  diffinition  of  "micro-computer"  is  not  easy, 
because  the  areas  of  its  techniques  and  applications  are  far 
extended.  Elementary  knowledges  of  microcomputers  hardware 
systems  is  offered. 

Program  For  Calculation  Of  CRC 


By  Itsuo  Yamaura 
Electrotechnical  Laboratory 

A program  that  calculates  CRC  (Cycle  Redandancy  Code) 
is  described. 

Microcomputer  Kits  Information 

Several  microcomputer  kits  is  introduced.  Comment 
on  each  kit  is  described. 

General  Information 

Reference  books  for  beginners  is  presented. 

’76  Lives  & Information  Fair 


Through  our  Club,  five  application  products  as 
below  are  to  be  displayed. 


Electronic  musical  instrument  by  microcomputer 
application  (Toshiba) 

Automatic  musical  performance  using  a training 
kit  (NEC) 
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0 Animation  drama  by  training  kits  using  a 
domestic  colour  TV  (NEC) 

0 Braille  printing  device  by  microcomputer 

control  (Welfare  Technology  Association) 

° Home-made  computer  (NS) 

Announcements 

1.  Microcomputer  Laboratory 

Workshop  which  serves  the  Club  members  with  lending 
assembly  tools,  assistance  for  debugging,  and  technical 
consultation  is  under  consideration. 

2.  Microcomputer  Symposiums 

Nine  Simposiums  will  be  held  in  autumn,  1976. 


First  Symposium  Oct.  2 
"NS  Microcomputers" 

Second  Symposium  Oct.  9 

"NEC  Microcomputers" 

Third  Symposium  Oct.  16 

"Fair  Child  Microcomputers 

Fourth  Symposium  Oct.  23. 

"Toshiba  Microcomputers" 

Fifth  Symposium  Oct.  30 

"Fujitsu  Microcomputers" 

Sixth  Symposium  Nov.  6 

"Hitachi  Microcomputers" 


by  Kenji  Fujimoto  (NS) 

by  Isao  Uchida  (NEC) 

by  Koichi  Hatakeyama 

(TDK  Fair  Child) 


by  Taiga  Hayashi  (Toshiba 

by  Shusaku  Ishihara 

(Fujitsu) 

by  Tsugiyuki  Watanabc 

(Hitachi) 
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Seventh  Symposium  Nov.  13 

"Intel  Microcomputers"  by  Nobuo  Kamata  (Intel  Japan) 

Eighth  Symposium  Nov.  20 

"Mitsubishi  Microcomputers"  by  Nobuo  Matoba  (Mitsubishi) 

Nineth  Symposium  Nov.  27 

"Motorola  Microcomputers"  by  Tadashi  Horicuhi  (MS) 

Mini-News 

1.  Up-to-date  Microcomputers  Peripherals 

Peripheral  equipments  for  microcomputers  must  be 
small  and  cheap.  Some  peripherals  which  were  recently 
published  are  introduced. 

2.  Micro-Communications 

Up-to-the-minute  applications  announced  in  U.S.A. 
are  described. 

Microcomputers  Application  Contest 


For  developing  techniques,  directing  a spotlight 
on  to  unknown  talents,  and  encouraging  new  ideas,  we  are 
planning  a contest  in  March,  1977.  Anyone  in  the  world  can 
be  an  entrant.  Subscription  should  be  sent  not  later  than 
Feb.  29,  1977.  Not  only  winners  but  also  all  the  entrants 
•v i 1 1 have  marvelous  prizes! 
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Companies'  activities  to  microcomputer  hobbyists  in  America 

By  Nobuhiro  Sato 
Sord  Computer  Systems 

Microcomputer  business  in  America  is  described  in  this 
article.  First, the  author  classifies  microcomputer  businesses 
into  three  groups  as  follows: 

(1)  Hardware  Sales 

(2)  Software  Sales 

(3)  Various  kinds  of  Services  Sales 

He  reports  that  most  of  the  American  microcomputer 
hobbyists  start  their  activities  by  buying  microcomputer 
systems  and  that  there  exists  a clear  distinction  between  a 
microcomputer  for  professionals  and  that  for  amateurcs. 

Second ly , processors , per ipherals , sof  t wares , computer- 
education  and  periodica]  publications  are  described  briefly. 

Finally, he  suggests  us  that  it  is  very  important  to 
consider  the  range  of  system  expandability  from  the  beginning. 


Microcomputer  magazines  in  America 

By  Haruhisa  Ishida 
University  of  Tokyo 

Following  famous  microcomputer  magazines  in  America 
are  introduced  briefly: 

(1)  Dr.dobb's  journal  of  computer  callisthenics  & Orthodontia 

(2)  BYTE 

(3)  Interface  Age 

(4)  Creative  Computing 

(5)  People's  Computer  Company  News 

He  recommends  us  to  read  any  of  these  magazines  to 
acquire  the  advanced  technology  and  American  microcomputer 
state  of  affairs. 
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Backside  stories  of  microcomputers 
(No.l)  l he  dawn  of  a microcomputer 
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By  Ryu  Ron 
Contribut ion 

How  and  why  the  microcomputer,  MCS-'t  .was  developed  is 
described  briefly. 

The  author  says,"  There  are  two  kinds  ol  di  uniat  ic  stories 
in  the  origin  of  microcomputers.  One  is  the  Silicon  Valley 
Story.which  is  related  to  the  production  technology  of  LSI. 

The  other  is  the  Electric  Calculator  Stories, which  are 
related  to  ideas  and  designs." 

This  No.l  story  tells  us  how  LSI  for  electric  calculator 
was  designed  and  that  it  was  only  INTEL  corporation  chat  tried 
to  develop  an  universal  standard  logical  device  to  satisfy 
various  kinds  of  desires  provided  from  a lot  of  Japanese 
calculator  makers. 

He  says  ,"  It  is  quite  ironical  that  the  Japanese 
calculator  makers, which  triggered  the  dawn  or  licrocomputer  age 
.went  bankrupt  before  the  prosperity  of  microcomputers  in 
these  days. 

( to  be  continued  ) 


How  to  assemble  microcomputers  (No.l) 


By  Shiniehi  Ikeno 

Nippon  Telegraph  & Telephone  Public 
Corporat ion .Musashino  Elec t r ica  1 
Communicat  ions  Laboratory 

He  is  going  to  report  not  only  how  he  designed  the  8008 
microcomputer  system  ,but  how  he  assembled  it.  This  No.l 
report  is  only  a preface  to  his  experimental  stories. 

( to  be  continued  ) 
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Present  state  ot'  microcomputers  and  their  future  (No.l) 


By  Yoshikuni  Ookawa 
University  of  Gifu 

The  author  describes  the  history  of  digital  computers, 
IBM  709  ( ’ 53) , PDP  5 (’63)  and-  INTEL  8008  (’73).  He  predicts 
that  something  extraordinary  will  happen  in  1983.  IBM  709 
is  characterized  as  a computer  for  borrowers.  PDP  5 is 
characterized  as  a computer  for  users.  INTEL  8008  is 
characterized  as  a computer  for  hobbyists. 

Relation  between  the  number  of  bits  in  a word  and  a 
proper  memory  size  is  described.  tie  indi  itc-s  the  following 
tub  1 e : 


word  size 
(bits) 

maximum  allowable  memory  size 
to  maintain  high  efficiency 

* 

2 k byte 

8 

8 k byte 

12 

lb  k byte 

L 16 

32  k bvte 

He  concludes  in  the  end  that  the  prosperity  of  8 bit 
microcomputer  is  entirely  dependent  on  the  number  of  problems 
that  can  be  programmed  into  8 k byte  memory  array. 

Whether  such  a problem  exists  or  not  will  be  discussed  in 
the  next  news. 

( to  be  continued  ) 


Microcomputers  and  our  daily  life 

By  Chikara  Sato 
Keio  University 

Most  of  the  people  say,"  In  a near  future, microcomputers 
will  make  great  effects  on  our  daily  life."  The  author  also 
says, "We  will  he  able  to  get  a lot  of  pleasure  from  microcomputer 
applications  at  homes, for  examples  T.V  games." 
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Miscellany  on  microcomputers 


By  R.B. 

Contr ibut ion 

Tho  author  discusses  the  instructions  and  architectures  of 
the  following  8 hit  microcomputers: 

(L)  8080  (INTEL) 

(2)  6800  (MOTOROLA) 

( 3)  6502  (Mos  Technology) 

(4)  SC /MR  (NS) 

(5)  F8  (FAIRCHILD) 

He  insists  that  256  byte  memories  are  enough  to  make  an 
ordinary  program  for  8 bit  microcomputers, for  example 
"Life  game"  and  "Fourier  analysis". 

New  products  informations 


(1)  Intel  iec  PROMPT  80 

-8080  microcomputer  design  aid- 

(2)  TEC-80A 

-8080  microcomputer  learning  device- 
Announcement 


(1)  First  Japan  Microcomputer  Club  Grand  Meeting 

Date  : 1976. Dec. 4th 
Time  : 1,30-5,00  (p.m.) 

Contents  : 

(a)  Grand  Meeting  (1,30-2,10) 

Opening  declaration  By  T.Hayashi 

Chairman's  address  By  S.Watanabe 

Reports  on  the  establishing  process 

By  K.Fuchi 

Reports  on  the  managing  policies 

By  H.Miura 

Closing  declaration  By  S.Narata 
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(b)  Memorial  Lectures  (2,15-4,00) 

Outline  of  Microcomputers  By  H.Aiso 

Microcomputer  clubs  in  America 

By  H. Ishida 

Microcomputers  and  Laser  By  K.Sakurai 

(c)  Party  (4,00-5,00) 

(2)  Microcomputer  Symposiums 

The  schedule  of  the  microcomputer  symposiums 
( from  Dec. '76  to  Apr.' 77  ) is  described  as  follows: 

10th  Dec. 11 

"Microcomputer  application  to  automation" 

11th  Dec. 18 

"Microcomputer  application  to  numerical  control" 
12th  Jan. 22 

"Microcomputer  application  to  electric  musical 
instruments" 

13th  Jan. 29 

"T.I.  microcomputers" 

14th  Feb. 5 

"Prolog  microcomputers" 

15th  Feb.  12 

"How  to  assemble  a T.V.  display" 

16th  Feb. 19 

"Microcomputer  application  to  industrial  processing 
17th  Feb.  2b 

"Electric  devices  controlled  by  microcomputers" 

18th  Ma  r . 5 

"How  to  learn  microcomputers 

-guidance  and  int roduc t ion- 
19  th  Mar. 12 

"How  to  select  microcomputers" 

20th  Mar. 19 

"Fundamentals  of  microcomputers" 

2 ' t h Ma r . 26 

"Know-How  of  microcomputer  assembling" 

22th  Apr. 2 

"Softwares  of  microcomputers" 
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23th  Apr. 9 

"Printer  interface" 

24th  Apr . 16 

"Casette  interface" 

25th  Apr. 23 

"Floppy  disk  interface" 

26th  Apr. 30 

"Tools  for  microcomputer  program  development" 

(3)  Service  for  acquisition  of  anything  necessary  for 
members 

For  the  convenience  of  members  to  make  a microcomputer 
system,  service  for  acquisition  of  anything  necessary  ,tor 
example  microcomputer  kits, power  supplies  and  parts  etc, 
is  introduced.  Male  order  is  , needless  to  say  , possible. 

(4)  Guide  to  a contribution 

A guide  for  a contribution  is  described  briefly. 
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(1)  Special  Subjects 

First  Japan  Microcomputer  Club  Grand  Meeting 
Chairman's  address 

By  Shigeru  Watanabe 
Tokyo  University 


Japan  Microcomputer  Cluo  received  a lot  of  approval  since  it 
established  on  1st  of  December.  He  thinks  people  who  organized  this 
club  are  pleased  to  know  that  there  are  many  Japanese  who  want  to  take 
this  opportunity  to  begin  studying  microcomputer. 

He  believes  it  is  very  important  for  Japan  to  create  something  unique 
to  Japanese  products.  Because  if  Japan  produces  products  which  are 
invented  in  foreign  countries  cheaply  and  exports  them,  it  always  creates 
fric  tion  between  Japan  and  other  countries. 

He  hoped  for  development  of  microcomputer  technique  in  Japan  in 
future  and  it  will  make  Japan's  microcomputer  technique  firm  and  well 
established. 


Reports  on  the  establishing  process 

By  Kazuhiro  Fuchi 
Electrotechnical  Laboratory 

Japan  Microcomputer  Club  now  has  a membership  of  about  500. 
Microcomputer  News  are  printed  bimonthly  in  English  with  the  aid  of 
Mr.  Umeda  and  others,  and  they  are  sent  to  U.S. 

Microcomputer  Symposiums  are  held  every  Saturday.  There  are  40  to 
110  members  attend  every  symposium.  It  is  held  not  only  for  the  members 
but  also  who  attends  the  symposium. 

Also  there  are  a lot  of  new  activities  planed  ahead. 


Reports  on  the  managing  policies 

By  Hirofumi  Miura 
Tokyo  University 

Accounting  report  November  30th 


Income 


Expenditure 


3,  000, 

000 

Yens 

2,  500, 

000 

Yens 

Membership 

500, 

000 

Yens 

Symposium 

3,  500, 

000 

Yens 

Printing  and 

Expenses 

Fee 


Communication 
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As  a result,  it  shows  a deficit  of  500,000  Yens,  but  we  have  500,000  Yens 
affears. 

Managing  policies: 

Because  the  communication  expenses  become  great  expenditure.  News  will 
be  printed  monthly  am!  it  will  become  a good  magazine  with  solid  materials. 


Special  lecture 

- Outline  of  Microcomputers  - 

By  Hideo  A iso 
Keio  University 

His  lecture  is  about  Microcomputer  technique  and  its  future. 

1)  Characteristics  of  I. SI 

LSI  as  well  as  all  semiconductor  is  based  on  mass  production. 

It  is  necessary  to  find  great  demands. 

Mass  production  is  essential  to  cost  down  and  it  will  increase  reliability. 

It  costs  a lot  more  on  a development  than  its  production. 

New  development's  test  costs  money  and  time,  and  unexpected  problems 
are  involved. 

2)  Limits  from  Microprocesser's  Structure  relation  among  Microprocessor's  j 

cost,  defect  and  size. 

3)  LSI's  blueprint  and  its  development  are  united.  How  to  find  out  a fault  in  a 
large  computer  is  very'  difficult  problem. 

4)  LSI  has  a great  influence  on  the  whole  electro-technique  field. 

5)  The  size  of  Microcomputer  and  Multiprocessor. 

6)  Electric  power  consumption  and  Interface. 

7)  Microcomputer  in  future. 

8)  Minute  processing  technique  and  device  for  VL.SI  (Very -Large  Scale  Integra- 
tion). 

Light  is  used  to  make  a blueprint  for  minute  processing  technique.  In 
order  to  increase  intensity,  the  technique  of  X ray,  electron  beam  and  Laser 
ray  are  used. 

To  make  device  itself  small,  new  development  of  a circuit  is  expected. 

9)  Actual  operation  density 

10)  Problems  of  Software 

The  problem  of  Software  is  on  the  productivity.  In  these  ten  years, only 
3%  has  been  improved  in  the  case  of  large  computers. 

11)  Variety  of  application. 

12)  Software  development  and  education. 


A 
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♦ New  Products  Information 


1) 

2) 


TI.CS-12A  KX12/10 

T3l'»0  Microcomputer  learning  device  and  design  aid. 

MCS48,  45  Microcomputer  series. 

New  CPl'8048  and  8085 


Microcomputer  Club  in  America 

By  Hisaharu  Ishida 
Tokyo  University 

Ue  reports  that  microcomputer  clubs  in  America  have  various  activities 
for  amateurs  to  enjoy.  Because  the  members  of  American  microcomputei  s are 
not  only  professors  and  researchers,  but  older  grammar  school  students  and 
high  school  students.  First  they  enjoy  playing  games,  then  learn  BASIC. 

Kits  m America  are  sold  cheaply  at  microcomputer  stores.  These  store- 
keepers help  amateurs  kindly,  and  they  hold  training  courses  and  sell  micro- 
computer magazines  and  books  of  their  interest. 

On  these  microcomputer  magazines,  there  are  articles  on  programming 
by  Basic.  Mr.  Ishida  thinks  it  is  very  useful  for  amateurs.  He  suggests  that 
microcomputer  magazines  should  help  amateurs  solve  Software  problems.  He 
also  wishes  for  standardization  so  that  it  is  cheap  and  easy  lor  amateui  s to 
exchange  their  Softwares  among  them. 


( 21  Visit  to  Akih abara 


By  Sanshiro  Kobayashi 

Tokyo  Industrial  Technique  Center 


He  introduces  good  shops  for  acquiring  materials  necessary  for  micro- 
computers in  Akihabara,  Tokyo. 


3 
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(3)  How  to  assemble  microcomputers  (No.  2) 

By  Shinichi  Ikeno 


Up  reported  how  he  assembled  his  second  microcomputer  6800  step  by 
step. 


(4)  Microcomputer  magazines  in  America 

By  Baruhisa  Ishida 


1.  Dr.  Dobb's  Journal  of  Calithenics  and  Orthodontia's  (Jan.  Feb.  Jun. /Jly. 
Aug.  Oct.  \ov.  /Dec.  1976)  articles  are  introduced. 

2.  BYTE  (Sept.  Oct.  1975,  Oct.  Nov.  1976) 

3.  Interface  (Oct.  1976) 

4.  Creative  Computing  (Sept. /Oct.  Nov. /Dec.  1976) 

5.  People's  Computer  Company  (Sept.  / Oct.  1976) 


(5)  Microcomputer  Short  Short  "Kapozon" 

By  Takashi  Kino 


It  is  a sorrowful  story  about  a young  wife  whose  hasband  is  a very  diligent 
microcomputer  technician. 


(6)  Microcomputer  And  Music 

By  Kohei  Sato 


Applications  of  microcomputer  for  music  composition  are  talked  briefly. 
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Hy  Setnosuke  Narita 


Japan  Microcomputer  Club  is  making  a plan  tor  authorized  examinations. 
He  explains  what  is  included  in  examination. 

1.  Outline  of  microcomputers 

Digital  Computer,  1C,  Memory,  Microcomputer  and  Microprocessor 

2.  Hardware  and  Digital  technique 

3.  Microcomputer  Software 

4.  Developing  tool  of  Microcomputer 


(8)  SC  I HP  Cassette-  Recorder  Interface. 

This  article  is  taken  from  Application  Note  of  National  Semiconductor  Co. 
Block  diagram,  Interface  > ircuit,  Memory  and  Address  Decorder  Circuit, 
recording  format,  data's  output  from  decorder,  write  mode,  receive  mode, 
and  waves  by  interface  circuit  are  explained  in  detail  by  diagrams. 

References. 

SC  MP  Technical  Description  (Pub.  No.  4200079) 

SC,  MP  l set's  Manual  (Pub.  No.  4200105) 

SC,  MP  Programming  a id  Assembler  Manual  (Pub.  .Vo.  4200094) 


(9)  [ tackside  stories  of  microcomputers. 


No.  2 The  down  of  a microcomputer 
Hy  Ryu  Kon 

The  successful  story  of  SEIKO  Personal  Computer  S 500  is  introduced. 


(10)  Announcements 


1.  The  first  microcomputer  symposium  Spei  ml  seminar 

Theme  Single  < 'innpiinrnt  Mie rncnmputc r "Mt'S  IH" 
l ecture  Nohtin  Kaniala 
Time  l-cbruary  Hth  . 

2.  Workshop 

° General  Consult  Day  will  he  held  once  a month. 

° Special  Invitation  to  Japan  Microcomputer  School. 

3.  News  from  Office 

Members  of  Japan  Microcomputer  Club  increased  to  630  and  spread  from 
Hokkaido  to  Okinawa.  The  large  part  of  them  is  the  twenties  and  thirties. 
Japan  Microcomputer  Club  began  to  draw  attntion  of  magazines  and  news- 
papers and  introduced  widely. 
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Creativity  and  Microcomputers 

By  Shigeru  Watanabe 
Professor  of  Tokyo  University 

He  points  out  that  the  ordinary  people  in  their  daily  Ufe  had  very  few 
contacts  with  the  large-scale  conventional  computers  before  microcomputers 
appeared.  Microcomputers  changed  this  situation.  Because  microcomputers 
have  two  advantages  which  the  large-scale  computers  do  not  have  handiness 
and  low  price.  This  change  is  due  to  the  development  of  central  processing 
unit  which  is  included  in  a microcomputer.  Anyone,  regardless  of  age,  can 
not  only  buv  a microcomputer,  but  also  can  develop  creativity  through  building 
and  using  microcomputers. 


Our  original  microcomputer 

By  Hirotatsu  Hashizume  & Ichiro  Ide 
Tokyo  University  T.S.G. 

Thev  are  physics  students  who  are  the  members  of  Tokyo  University 
Theoretical  Science  Group.  They  built  their  original  microcomputer  with  a 
front  panel  without  using  a manufacture's  KIT.  Two  problems  were  to  find  a 
low  cost  teletypewriter  and  to  put  long  programs  into  their  microcomputer 
which  only  has  RAM.  The  first  problem  was  solved  by  using  second-hand  tele- 
typewriter (interfaced  with  TTY  controller)  and  the  second  one  was  by  using 
Hexadecimal  program  paper  tapes. 

Thev  wish  there  will  be  more  exchanges  of  information  about  software  of 
microcomputers  to  help  members  who  wish  to  build  an  original  microcomputers. 


How  to  sell  the  technology 

By  Yoshikuni  Okawa 
Professor  of  Gifu  University 

He  points  out  the  difference  between  American  and  Japanese  research 
institutions'  system  of  making  profits  from  their  developed  technology.  In 
Japan  the  concept  of  multiclient  job  system  has  not  yet  been  introduced.  He 
believes  it  will  bring  many  profits  to  Japanese  research  institutes. 


Available  liny  BASK'  source  tapes  for  the  HOHO 

By  llaruhisa  Isi»ia 
Professor  of  Tokyo  University 

Palo  Alto  version  of  Tiny  BASIC  source  tapes  and  its  application  "Tiny 
Star  Trek"  are  available  from  Tokyo  University  microcomputer  class  with 
the  help  of  Community  Computer  Center  in  U.S. 


1 
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How  to  make  a choice  for  mil' rocomput ers 

Uv  Kazuhide  Masugi  k Yasumi  Tokuhara 
Astar  International  Co. , Ltd. 

This  article  includes  charts  which  classify  microcomputers  bv  features, 
purposes,  prices,  and  representative  products.  He  suggests  these  following 
points  should  be  considered  carefully:  the  selection  between  the  8080  and  the 
6800,  between  KIT  and  completed  products,  a balance  between  features  and 
prices,  and  extensibility  aiu  buckup  system. 


How  to  assemble  m i e rocomputers 
By  Shinichi  Ikeno 

Nippon  Telegraph  A Telephone  Public  Corporation, 

Musashino  Electrical  Communications  Laboratory 

This  article  explains  how  to  use  CMOS  memory  for  applications  of  programs. 
He  reminds  us  that  in  order  to  use  higher  programming  language  the  memory 
should  have  at  least  4K  Byte.  Therefore  the  place  for  the  extension  of  bus 
driver  should  be  considered  before  hand  on  CPU  substrate  board. 


American  Microcomputer  Magazine 


By  Haruhisa  Ishida 

Assistant  Professor  of  Tokyo  University 


"Personal  Computing",  "Dr.  Dobb's  Journal",  "Interface",  "Interface  Age", 
and  "Byte"  are  introduced.  One  of  the  interesting  article  is  large  volume 
distribution  of  softwares  in  forms  of  Bar-Code  printed  on  papers. 


House  wife  and  Microcomputer 


By  Ritsuko  Yokotsuka 


This  article  describes  her  motives  for  joining  this  club.  She  has  a 
experience  of  software  programming  and  before  she  got  married,  she  worked 
with  computers.  Her  dreams  came  true.  Even  though  she  has  to  take  care 
of  her  children  and  house,  she  was  looking  for  an  opportunity  to  those  who 
are  in  the  same  situation  like  hers. 
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An  no  urn  ement 

(|l  Activities  of  Japan  Microcomputer  Club 

(a) Editonul  Come  illee 

"Mu Hu mnputo:  magazine  lias  boon  an  organ  of  Japan  Microcomputer 
Club,  but  now  it  is  oxpis  ted  to  extend  its  serv  i.  e bv  making  an  ot  ^an  to  a 
microcomputer  technical  magazine  which  includes  articles  of  assembling 
nucroconiputi'is, 

(b) Kesearch  and  Investigation  Committee 

It  plans  to  ho  la  regular  seminars,  special  seminars  and  exhibition  of 
member's  works  approximately  JO  or  JO  times  a year, 

(c)  Microcomputer  1 uboratory 

It  offers  a place  for  exhibitions  of  original  works,  and  for  work  shops 
to  members  .if  the  club. 

(d)  Microcomputer  Stun. la rd nation  Committee 

Making  reference  to  Kansas  City  standard,  it  holds  technical  investi- 
gation of  Audio  Set  standard.  It  is  expected  to  lie  of  service  to  niembets 
for  exchangemg  microcomputer  programs  and  data. 

(e) Microptogram  Library  Committee 

Its  purpose  is  to  facilitate  exchanges  of  programs. 

(OMicrocomputer  Contest  Committee 

This  committee  already  held  a exhibition  of  microcomputer  works  and 
contest.  It  helped  to  participate  m Business  Show'  (promoted  by  Japan 
Management  Association)  and  ' Microcomputer  Show"  (sponsored  by  Japan 
Electronic  Industry  Promotion  Association)  in  lokyo. 

(g)  Mic rocomputer  Engineer  Examination  Committee 

Its  mam  purpose  is  to  examine  microcomputer  engineers  and  technicians 
in  basic  techniques  and  knowledge. 

(h)  Microcomputer  Organization  Committee 

In  order  to  promote  communications  among  the  local  members,  there 
are  several  plans  to  establish  branches  of  Japan  Microcomputer  Club.  The 
first  branch  was  established  in  Nagano  District. 

(i)  Microcomputer  Planning  Committee 

The  inspection  trips  to  universities  and  manufacturers  and  exhibitions, 
and  overseas  investigation  group  trip  are  planned. 

(J)  I'he  schedule  of  microcomputer  research  seminars 

Microcomputer  research  seminars  are  oiv  i.ieii  into  micocomputer  regular 
seminars,  special  seminars  and  presentation  of  microcomputer  researches. 
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April  9 
April  23 
May  U 
May  28 
June  ll 
June  25 
July  9 
July  23 
August  13 
August  27 

(3)  "Microcomputer  Circular"  magazine 

This  is  used  as  a source  material  for  microcomputer  research  seminars 


Microcomputer's  software  t 

Interface  of  printers 
Interface  of  cassettes 
Interface  of  floppy  disc 
Microcomputer  development  tools 
MOST  EC  K Corp's  microcomputers  (2-80) 

Interface  of  Magnetic  Drams 
Heginners'  Microcomputer  Programming 
BIT  Slice  Computers 
HU-IB  Interface  and  microcomputers 


Japan  Microcomputer  Club 

Kikaishinko-Kaikan,  JEIDA 

5-5-8,  Shiba-Koen,  Minato-ku,  Tokyo, 


( 1 ) Overseas  Special  Report  1 

( 2 ) The  Selection  of  Microcomputer  Devices  1 

( 3 ) Peripheral  Devices  for  LKIT  - 16  1 

( 4 ) What  is  a low  cost  Training  Kit  MP  - 80?  1 

( 5 ) Character  Display  2 

( 6 ) Stable  power  supply  for  Microcomputer  2 

( 7 ) NIBL  2 

( 8 ) MEK  6800  Motorola  Microcomputer  DII  Kit  • • 2 

( 9 ) Interface  for  X-Y  Plotter  2 

(10)  TINY  BASIC  3 

MICROCOMPUTER  NEWS  3 

* Research  Seminare  for  Microcomputer 

* Japan  Microcomputer  branches 

* From  Office 
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Overscas  Special  Report 
"American  Microcomputer  Hobbyists" 

Chikara  Sato 

Professor  of  Keio  University 

He  reports  the  First  West  Coast  Computer  Fair  in  San  Francisco  and  the 
Electro  '77  in  New  York.  The  statistics  shows  the  American  microcomputer 
hobbyists  characteristics.  It  shows  also  that  American  Hobbyists  are  interested 
in  microcomputers  which  cost  more  than  $2,  000  rather  than  ¥300  one-board 
kit.  Their  tendency  is  shifting  from  TV  games  to  more  complex  and  sophisticated 
games  like  higher  level  computing  program  and  business  games. 


The  Selection  of  Microcomputer  Devices: 

"What  would  be  your  best  selection  of  devices?" 

Group  Akaza 

This  describes  many  types  of  one-board  kit  with  CPU,  HOM,  RAM  and 
interface.  The  focus  is  on  the  one-board  kit  which  can  be  used  as  a part  of 
circuit  (process  controller)  when  the  expanded  functions  are  acquired,  and 
also  can  be  expanded  to  multi  purpose  microcomputer  in  order  to  become  a 
bases  for  program  developing  implementations.  Intel  SDK-85,  NEC  TK-80, 
MT  corporation  PROTO- 80  and  various  other  companies'  kit  are  introduced 
with  detailed  descriptions. 


P c ri pheral  Devices  for  I, KIT-16 

It  explains  step  by  step  how  to  expand  functions  of  microcomputer.  It 
devided  into  power  supply,  programming,  connection  to  tape  recorder,  auto- 
matic music  performance,  and  connection  to  TV  set. 


What  is  a low  cost  Training  Kit  MP-80? 


Yoshi  Ishida 

Logic  Systems  International 


It  advises  the  beginners  hou 
kit,  programming,  and  cost  of  kit 
buy  a new  kit. 


• o cope  with  the  problems  about  building  a 
vi.  o the  expanding  ability  when  the  users 
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Nobuhiro  Kijikawa 
Nagano  Microcomputer  Club 


It  is  about  how  to  build  a CRT  Character  l)isplay  by  $100. 


Stable  power  supply  for  Microcomputer 
Sanshiro  Kobayashi 

It  is  about  direct  current  stable  plwer  supply  by  serial  control  method. 


NIBE 

Masuda 

National  Semiconductor 

This  is  a serial  article  which  describes  the  interpreter  N1BL  for  TINY- 
BASIC  to  operate  on  SC/MP  chip.  NIBL  can  be  executed  by  SC/MC  II  CPU. 
4K  byte  ROM,  2K  byte  RAM,  teletype  and  can  implement  the  users'  program 
into  ROM.  The  article  includes  the  required  hardwares,  multipurpose  I/O 
function,  P-ROM,  basic  programming. 
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MEK  6800  Motorola  Microcomputer  DII  Kit 

Toshio  Nakazawa 
Kanazawa  Technical  College 

This  shows  very  technical  building  method  of  MEK  6800. 


In  t e rf ace  for  X - Y Plotter 

Naofuini  Nakajima  & 
Yasujuki  Suzuki 
Tokyo  University 


* t"  n i k<-  t program  for  numerical  value  control  positioning 
• ' <•  • sing  lut'd  ■ h I ) - ' R0 . The  flow  chart  and  complete  program 
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T1NV  MASK*  : Prog  ramn  \ i ng  a ml  features 

Kiyoshi  Saito 
KMC 

BASH  has  many  toaturcs  which  arc  very  useful  lor  microcomputers. 

1 simple  programming  grammar 

2 operations  are  easy  because  compiller  and  assembler  are  unnecessary. 

3 immediate  execution  is  possible  by  inputting  a part  of  a program  and  re- 
execute  after  modi fieatioi  s are  made. 

He  suggests  readers  to  make  BASIC  interpreter  by  oneself  in  order  to  enjoy 
programming,  to  make  a interpreter  suits  best  to  one's  own  purpose,  to 
modify  the  interpretin’  in  case  of  a expansion  of  hardware  functions. 

Required  hardwares,  the  functions  of  interpreter,  input  parts,  programming 
control  command  execution,  and  terms  in  flow  charts  are  wxplained. 


MICROCOMPIJTFK  NFWS 

1 Research  Seminarc  for  Microcomputer 

1 Introduction  to  Microcomputer  Programming 

2 Hit  Slice  Computer 

3 Microcomputer  Devise;  TOSHIBA,  HITACHI,  FUJITSU  products. 

•1  CAMAC  interface  and  Microcomputer 

f>  III’  IB  Interface 

6 Microcomputers  - Pana  Fa  com  Micro  Cassette  recorder 

7 Introduction  to  BASIC 

8 Interface?  with  Audio  Cassette 

!)  Control  Program  for  f loppy  Disc 

10  DMA  production 

1 1 Use  of  1C  memory 

12  Use  of  TTF: 

2 Japan  Microcomputer  Club  branches  arc  established  in  many  parts  of  Japan, 


* * 
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3 Fro m Office 

News  letters  from  microcomputer  clubs  in  America  are  arrived. 

1 Amateur  Radio  Research  and  Development  Corp. 

2 Rochester  Area  Microcomputer  Society 

3 Philadelphia  Area  Computer  Society 

4 North  Orange  Country  Computer  Club 
5 Northwest  Computer  Club 

6 Southeastern  Michigan  Computer  Organization 

7 Amateur  Computer  Croup  of  New  Jersey 

8 Technological  Developments 
!)  The  Computer  Faire 

10  National  Semiconductor  Co. 
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Japan  Microcomputer  Club 

Kikaishinko-Kaikan,  JEIDA 

5-5-8,  Shiba-Koen,  Minato-ku,  Tokyo 


( 1 ) Microcomputer  Family  

( 2 ) Peripheral  Devices:  Mini  printer.  Key  board,  Encloder  and 

TV  display  

( 3 ) What  are  the  interface  devices?  

( 4 ) The  Complete  Production  of  FSK  Cassette  Interface 

( 5 ) Microcomputer  Protector  

( 6 ) Prerequisite  for  BASIC  

( ? ) Microcomputer's  Future  and  Current  Cituation  

( 8 ) CRT  Display  Device  

( 9 ) Random  Number  Table  

( 10  ) Microcomputer  Programming  

( 11  ) Assembler  Language  and  Program  Input  

( 12  ) F8  Micro  Machine  (MMI)  

(13  ) N1BL -Application  number  One  

SC/MP-Disassembler  

(14)  Microcomputer  Glossary  

MICROCOMPUTER  NEWS  


Digest  Translated  from  Japanese  Edition 


Vol.  2,  No.  4 October,  1977 
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Microcomputer  Family 

It  is  a serial  report  on  the  actual  example  of  hobbyists  enjoying  micro- 
computer at  their  homes.  The  pictures  show  that  a family  enfoying  synthe- 
sized music  and  graphic  art  controlled  by  microcomputer  with  neighbor 
children. 


Peripheral  Devices:  Mini  printer.  Key  board.  Encoder  and  T.  V.  display 

TK  80  NEC)  can  have  1 K byte  ROM  and  1I<  byte  RAM  plugged  on  board. 
But  in  order  to  make  it  fit  for  multi-purpose  by  extending  RAM  and  I/O 
externally  it  is  necessary  to  put  buffer  in  address  bus. 

As  a character  display  for  microcomputer  Adteck  System  Science  Co. 
Television  Character  Display  Unit  is  selected  because  this  can  provide  more 
functions  than  Video  RAM  in  compact  size  and  the  price  is  about  $130 
including  the  modulator  to  T.  V. 

An  electric  discharge  printer  unit  in  which  the  complete  interface 
circuit  are  included  can  print  only  by  inputting  the  ASCII  code. 


What  are  the  interface  devices? 

A key  board  encoder  consists  of  a key  board  arranged  like  a type-writer  and 
LSI  encoder  which  inverts  signals  into  standard  codes  like  an  TSCII 

As  a T.  V.  display  a character  display  is  chosen  because  the  same  number 
of  byte  as  the  number  of  characters  is  needed  for  memory.  Even  a character 
display  can  not  show  an  arbitary  diagram  its  program  is  much  easier  than 
a graphic  display. 

Digital  Cassette  tape  memory  device,  interface  for  audio  tape  recorder, 
electric  discharge  and  heat  sensitive  printers,  floppy  disc,  character 
display  terminals  are  explained  and  many  real  products  from  various 
companies  are  listed. 

'] 

The  Complete  Production  of  FSK  Cassette  Interface 

This  article  advises  you  to  use  FSK  (FM  Type)  modulation  method 
because  of  low  noise  and  usefullncss  to  exchange  data  through  telephone 
lines  and  amateur  wireless. 

When  there  is  not  any  frequency  member  counter  or  other  measuring 
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instrument  available  any  musical  instruments  will  be  of  use  to  regulate 
frequency. 


Microcomputer  P rotector 

This  microcomputer  protection  is  for  excess  voltage  to  flow  into  the 
wrong  circuits.  It  consists  of  OP.  AMP,  zener  diode  and  SCR.  Detailed 
SCR  selection  points  are  described. 


Prerequisit e for  BASIC 

As  a CPU  board  KIM-1  using  6502  and  8 K byte  RAM  board  and  CRT 
display  are  necessary  to  enjoy  BASIC.  The  total  cost  of  devices  would  be 
about  $150. 


Microcomputer's  Future  and  Current  Cituation 

Microcomputers'  function,  features,  and  merits  of  finished  products 
are  discussed.  SOL  Microcomputer  which  is  a developped  products  by 
Processor  Technology  Co.,  in  California  is  introduced. 


CRT  Display  Device 

This  display  device  is  able  to  draw  complex  characters  by  combination  of 
basic  patterns  such  as  circle,  square,  triangle  and  line  on  static  electricity 
deflected  CRT  like  an  oscilloscope.  Not  only  a static  pattern  but  also  a pattern 
can  be  moved  dinamically  by  a internal  program  and  by  receriving  analog 
voltage  directly  fro m outside. 

Hardware  structure.  Software  and  examples  of  applications  are  described 
with  diagrams. 


Random  Number  Table 

This  is  an  introduction  to  BASIC  programming. 

Microcomputer  Progra mming 

This  includes  two  basic  simple  program:  TK-80  square  root  program 
by  subtracting  odd  numbers,  and  expansion  memory  checking  program. 
Plow  charts  and  the  complete  programs  are  listed. 
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Assembler  I anguage  and  Program  Input 

Assembler  Language  programming  are  described  step  by  step  with  an 
example  using  LIKT-16. 


F8  Micro  Machine  (MM1) 

Fairchild  Co.  product. 

One  chip  microcomputer  F8  Micro  Machine  is  developed  with  the  n-channel 
silicon-gate  MOS  technique.  It  can  be  used  for  an  application  to  low  cost 
controller.  Basic  functions,  features,  interrupt  control  circuits,  multi-chip  F8, 
Instruction  Set  are  explained  in  detail. 


NIBL-Applieation  number  One. 

SC  / M P-  Disassembler  

Disassembler's  structure,  instruction  set,  additional  hardware,  and 
execution  of  SC/ Ml’  disassembler  are  described. 


M i c roc ( 'input e r Glossa  ry 

Letter  and  Questions  from  Headers. 


MICROCOMPUTER  NEWS 

I Regular  Seminar  J 

This  will  be  held  from  November  and  divided  into  three  courses; 
beginner,  intermediate,  advanced. 

The  themes  for  each  course  such  as  microcomputer  building  and  software 
basics;  Interface  and  Application  Programming;  Assembler  and  Macro  Program- 
ming are  just  a few  examples. 
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APPENDIX  I 

LIST  OF  REGISTRANTS 
FIFTH  INTERNATIONAL  MEETING 
INTERNATIONAL  PURDUE  WORKSHOP 
ON  INDUSTRIAL  COMPUTER  SYSTEMS 
October  3-6,  1977 


Alcoa,  Alcoa  Bldg.,  Pittsburgh,  PA  15219  (412/553-3790) 

James  E.  Owens,  Coordinator-Process  Control 
Computer  FAB 


American  Chain  and  Cable  Corporation , (ACCO) , Bristol  Process 
Division,  40  Bristol  Road,  Waterbury,  CT  06720  (203/ 
756-4451) 

Walter  A.  Duncan,  Manager  Software  Development 
Engineering 

Applied  Automation,  Pawhuska  Road,  Bartlesville,  OK  74004 


Applied 

<9 


James  B.  Klahn,  Engineer/Analyst  (918/661-3432) 
Dick  Thompson,  Computer  Products  Engineer 


Atlantic  Richfield  Company , 400  E.  Sibley  Blvd. , Harvey,  IL 


Company 

)-3000) 


Robert  C.  Milam,  Jr.,  Senior  Engineer 


Bailey  Meter  Company,  29801  Euclid  Ave.,  Wickliffe,  OH  44092 


r Meter  company 
r2l6/943-5500) 


J.  C.  Cermak,  Systems  Analyst 

Thomas  L.  Willmott,  Manager  Computer  Systems 
(Ext.  2277) 


B.  F.  Goodrich  Chemical  Company,  6100  Oak  Tree  Blvd.,  Cleve- 
land, OH  44131  (21675^4-0200) 

Robe.  F.  Carroll,  Manager  Systems  Engineer 


British  Steel  Corporation,  140  Battersea  Park  Road,  London 
SWll,  England  (01-6^2-5511) 

David  N.  Shorter,  Manager  Real-Time  Computing 


Case  Western  Reserve  University,  University  Circle,  Cleveland, 

OH  44106  (216/368-4078) 

Dr.  Janos  Gertler,  Systems  Engineering  Department 

(On  leave  from  the  Hungarian  Academy  of  Sciences) 


Celanese  Corporation,  P.  0.  Box  1414,  Charlotte,  NC  28232 

rws'sr-^ir 

W.  V.  Brown,  Manager  Automation  and  Control  Systems 


Cominco  Ltd.,  1385  Cedar  Ave . , Trail,  B.  C.,  Canada  V1R4C3 
(6037364-4876) 

Tom  Farenholtz,  Systems  Engineer 


Cummins  Engine  Company,  1000  5th  Street.,  Columbus,  IN  47201 
(512/379-6710) 

Lyle  L.  Simon,  Manufacturing  Systems  Specialist 


Dartmouth  College , Hanover  NH  03755  (603/646-2080) 

Dr.  Gordon  M.  Bull,  Office  of  Academic  Computing 


Defense  Advanced  Research  Proiects  Agency  (DARPA) , 1400  Wilson 
Blvd. , Arlington  VA  22209  (202/694-113^ 

Lt.  Col.  William  A.  Whitaker,  Special  Assistant  to 
the  Director 


Eastman  Kodak  Company,  Kodak  Park  Division,  MSD  Bldg.  69, 
Rochester,  NY  H650  (716/458-1000) 

Kenneth  Lee,  Systems  Designer,  Management  Service 
Division  (Ext.  74628) 


E.  I.  du  Pont,  101  Beech  Street,  Wilmington,  DE  19898  (302/ 

7T2T-T735) 

Robert  S.  Crowder,  Jr. , Senior  Engineer  Associate 

Stephen  C.  Schwarm,  Development  Engineer  (302/774- 
1669) 
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Electrotechnical  Laboratory,  5-4-1  Mukodai,  Tanashi,  Tokyo 
(0424-61-2141) 

Koji  Yada,  Manager 

Erlangen,  University  of,  Erwin-Rommel-STRl , Erlangen,  FEDERAL 
REPUBLIC  OF  GERMMY,  D-8520  (09131/857080) 

Dipl-Phys.  Peter  F.  Elzer,  Tandemlab  of  the 
Physics  Institute 

Exxon  Research  and  Engineering  Company,  P.  0.  Box  101,  Florham 
ParkTNJ  079T2"  (?0 1/474-58^ 

Ara  Barsamian,  Senior  Project  Engineer 

Remsi  Messare,  Senior  Project  Engineer  (201/474-1374) 

Fischer  and  Porter  Company,  County  Line  Road,  Warminster,  PA 

IE9  7^T(  2T57  6 74-  64^) 

Shoji  Fukumoto,  Manager  Software  Development,  DCID 
Richard  P.  Sanders,  Manager  (215/674-6493) 

Foxboro  Company , Foxboro,  MA  02035  (617/543-8750) 

Richard  H.  Caro,  Principal  Research  Engineer 


General  Motors,  General  Motors  Technical  Center,  Warren,  MI 

4S095 


Bob  Campbell,  Senior  Project  Engineer  (313/575-0923) 

William  F.  Fraker,  Engineer.,  Quality  Control; 

Delco  Remy  Division  of  General  Motors,  Dept. 
134B,  2401  Columbus  Ave.,  Anderson,  IN  46011 
(317/646-2643) 

Mary  S.  Pickett,  Associate  Senior  Computer  Scientist, 
Computer  Science  Dept.,  General  Motors 
Research  Lab. , (313/575-3190) 
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Hitachi,  Ltd.,  1-5-2  Omika,  Hitachi,  Ibaraki,  319-12,  Japan 

^295^33-1111) 

Masayasu  Kato,  Engineer,  Omika  Works 


Honeywell,  Incorporated,  1100  Virginia  Drive,  Ft.  Washington. 

PA  19034 

A1  Bates,  Product  Planner,  2222  W.  Peoria  Ave., 
Phoenix,  AZ  (602/943-2341) 

C.  Diefenderfer , Principal  Development  Engineer, 

1100  Virginia  Drive,  Ft.  Washington,  PA  19034 
(215/643-1300  - Ext.  426) 

Charles  Farmer,  Manager,  1100  Virginia  Drive,  Ft. 
Washington,  PA  19454  (215/643-1300  - Ext.  405) 

Yoel  Keiles,  Principal  Design  and  Development 
Engineer,  Application  Research  TDC,  1100 
Virginia  Drive,  Ft.  Washington,  PA  19454 
(215/643-1300  - Ext.  507;300) 


Honeywell  Information  Systems,  300  Concord  Street,  Billerica. 
MA  01821  (617/667-3111) 

Peter  Brewster,  Secretary  Head 

IBM  Corporation,  P.  0.  Box  1328,  Boca  Raton,  FL  33432 

Alex  J.  Arthur,  Staff  Programmer,  555  Bailey  Ave., 
San  Jose,  CA  95046  (408/463-4085/3312) 

Dr.  Thomas  J.  Harrison,  Senior  Engineer  (305/994- 
2766) 

Dr.  T.  W.  Daniel  Sze,  Engineer  (305/994-3095) 


I.C.I.  Limited,  Corporate  Lab.,  P.  0.  Box  11,  The  Heath,  Run- 
com,  Cheshire,  England,  WA740E,  (09285-73456) 

J.  R.  Halsall,  Manager  Research  Association 
(Ext.  3490;  Secy-3991) 
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Inland  Steel  Company,  Mail  Station  2-465,  3210  Watling  Street, 
East“Chicago,  IN  46307  (219/392-5672) 

Earl  E.  Creekmore,  Process  Control  Engineer 


Institute  for  Automatic  Control , Voltrastrasse  18,  Zurich, 
Switzerland,  CH-8044  (01/321060) 

Dr.  Thierry  Lalive  D'Epinay,  Eidg.  Techn. 
Hochschule 


Intel  Corporation,  3065  Bowers  Ave.,  Santa  Clara,  CA  95051 
J.  Drakeford,  Product  Manager 
John  Zarrella,  Senior  Engineer  (408/988-2444) 


Interdata  Inc.,  106  Apple  Street,  Tinton  Falls,  NJ  07724 
(201/757- 7300) 

Edward  J.  Wilkens , Manager  (Ext.  435) 


IRIA,  Domaine  de  Voluceau  Rocquencourt  F 78150  LeChesnay, 
France  (1/9549020  tx  697033  F) 

Nicolas  E.  Malagardis,  Director  of  Bureau  of 
Standards 


Leeds  and  Northrup  Company,  Sunneytown  Pike,  North  Wales,  PA 
17554'  (215/643- 2000) 

Eric  G.  Sellix,  Senior  Project  Engineer 
(Ext.  8518) 


Merck  and  Company,  Inc.,  Rahway,  NJ  07065  (201/574-5183) 

Thomas  G.  Gaspar,  Director  Automation  and  Control 


Metromation,  1101  State  Road,  Princeton,  NJ  08540  (609/924 

37W 

Robert  A.  Williamson,  Jr.,  Manager  of  Product 
Planning 


J 


-408- 


Modular  Computer  Systems,  M.S.  #55,  1650  McNab  Road,  Ft. 
Lauderdale , FL  33309  (305/974-1380) 

Kamal  Bitar,  Technical  Manager,  Software  Develop- 
ment 


National  Bureau  of  Standards,  A130  Technology,  Washington, 
D.  C.  20234~T301/92l-2381) 

Dr.  Gordon  J.  VanderBrug,  Project  Manager 


National  Research  Council  of  Canada , Bldg.  M3,  Ottawa, 
Canada  K1A0F 


Dr.  R.  W.  Gellie,  Research  Officer 


Naval  Ocean  Systems  Center,  Code  8221,  271  Catalina  Blvd 
San  Diego,  CA  92000  (714/225-2480) 

Warren  Loper,  Computer  Specialist 


Naval  Weapons  Center,  China  Lake,  CA  93555  (714/939-3561) 

Robert  D.  Hawkins,  Microprocessor  Design 
Coordinator 


Norwegian  Institute  of  Technology,  Division  of  Engineering, 
Cybernetics , 703?  Trondheim-NTH , Norway  (075-94352) 

Odd  Pettersen,  Associate  Professor 


Olin  Corporation,  120  Longride  Road,  Stamford,  CT  06880 
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